Discovering semantics (Was Re: an unfilled need)

[Matthew Gertner]

> Precisely! But the number of potential applications is infinite. The
> amount of stuff you would need to "discover" is infinite. That
> is why inventing declarative syntaxes for discoverable knowledge
> such as rendering semantics, interactive behaviour, computation
> etc. will always be a sandwich short of the full picnic.

And rightly so, since this will enable software vendors to create their
own sandwich, keeping the idea market open to innovation and progress.
But that still leaves a hell of a lot of beer and potato salad for the
standards makers:

1) Associating element types with rendering semantics
Everyone agrees on this. We want a default way to view a document in a
browser in some readable way. Right now the stylesheet associated with a
document is specified in the document instance, but it could just as
easily be placed in a central repository and retrieve via query. In
addition, there's obviously no reason why several stylesheets couldn't
be associated with a single document, au choix. I'm way out of my depth
here, but presumably if font-makers can come up with universally
understandable, orthogonal attributes like "sans serif", "bold" or
"italic", then the same could be done for stylesheets. I'm no expert on
aesthetics, but this would be cool even if I just got a list of
available stylesheets with a descriptive name for each when I access a
document.

2) Associating element types with other semantics
...maybe in the form of Java classes (beans or otherwise). You won't get
a fully fledged application, of course, you could at least have a
standard method for viewing (which might well be done through some other
means than a stylesheet -- imagine a CML document), printing and
editing. And there's no reason why arbitrary methods could not be
available too. So I receive my "invoice" document and go to the central
semantics repository to see what methods are available for it. If I find
a method for, say, calculating the total price of the invoice, I don't
have to duplicate this code in my application.

Objections to putative methods for discovering semantics tend to be
based on unrealistic expectations about what this could do. There isn't
any need for "Java ontologies" or code that works everywhere in every
situation in order to do useful stuff. If I can publish my schema in a
central place alongside some code, then I am providing far more for
others to reuse than if I publish the data alone. If others can extend
my code (through aggregation or -- please! -- inheritance) then there is
a real chance that a rich set of reusable syntaxes and associated code
will spring up organically for a variety of application domains. So what
if I have to go query the repository by hand and then hard-code the link
to the appropriate application logic into my document instance? And if
someone manages to figure out some basic hierarchical organization for
the repository, a la Yahoo, well it would seem petty to bicker about a
missing sandwich or two...

Matthew

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)