RE: language modularity, with semantics

Some people call those code lists.  They implement 
a drop down box, an extensible code list and move on. 
Simple.  The web architecture is not concerned; application 
language designers are and semantically, they may only 
care that the term is in a form (say datatype) which 
can be used in a report (usually a string).  The 
web architecture does not care how either end of a 
communication or 'response point' as you label this 
inteprets a code list.  If one must care about this,
that is done by creating an object model in the 
application language standard or specification.  
Then they register a handler. 

X3D does this.  Most application languages with 
both rendering and behavioral fidelity requirements 
do this.  Semantics are not what XML or namespaces 
do.  They like any URI-name application can indicate 
that, but it is meaningless to the XML processor. 
It is just a code to pass to the application processor.

Why should the web architecture care about application 
language semantics?   I'm on record as saying that 
the W3C shouldn't either.  It's a nice job for orgs 
such as OASIS, Web3DC, etc., but given the range of 
rot involved with indemnity issues, patent rights, 
and so on, it is a bad place for the W3C to tie up 
assets.

The web architecture really shouldn't care about 
the semantics of application languages.  It is a 
communication enabling system, not a communicator. 
Different layers; different rules; same addressing 
system.

The application semantics modularity model is a 
problem of the object models, not XML or namespaces 
any more than they are a problem of URIs.  We 
can't treat interoperation by the same means as 
we join relational tables.  It's nonsense.  Try 
putting an SVG handler inside an X3D texture. 
Doable?  Yes.  Meaningful? Depends.  Good engineering? 
Undetermined: the performance of the objects is 
doubtful but that is something for experimentation.

len


From: Sandro Hawke [mailto:sandro@w3.org]

[3rd branch of original message]

> No, look. Interoperability does NOT require that we pick a single 
> fixed semantics. All it requires is that your semantics for the URI 
> and my semantics for it are *compatible*. 

I don't understand well enough how to talk about the semantics of URIs
to argue this point.  Mostly I was trying to say the same thing you
said wonderfully last week [3]:

     Semantics is centrally relevant to the Web, because the entire
     point of the Web is to convey representations from place to
     place, and it is only semantics which makes a representation
     distinguishable from random noise.  

Of course in general, MIME/Content types address the basic problem
here.  Bytestrings are always transmitted on the web (and usually in
SMTP) as MIME Entities, and MIME Entities always start with a header
which includes a string (the "Content-Type") which maps, via a central
registry, to a specification of the intended language of the body
bytestring.  This is simple, obvious engineering, like using ISO
country/language codes to indicate whether a given string ("chat") is
meant to be understood in French or English.

The technical question which is slowly coming to a boil is: How To
Make Modular/Composible Languages?  The design of a standard web page
language is too big for one committee, so how can we break it into
HTML + MathML + SMIL + SVG + whatever...?  And it gets far, far worse
if we want to include markup for parts inventories, business hours,
delivery policies, and all the other domain knowledge people want to
share on the web.   It's too big for one committee, but we just make
it "user defined" there will be no interoperability between user
communities. 

XML namespaces are a baby-step [4] toward addressing this problem in
XML, giving some degree of independence between module (markup
language) creators, but still not even providing hooks for allowing
arbitrary combinations of language modules to have well defined
semantics.

Others have said "if you want to mix namespaces in XML, write in
RDF/XML" which comes a lot closer to an answer.

But it still hasn't reached the answer if RDF without semantic
extensions and RDF with semantic extensions are tranmitted with the
same MIME type, has it?  OWL is a semantic extension of RDF, right?
If it's transmitted with the same MIME type as plain RDF, the reader
wont be able to tell whether the writer intended the OWL semantics or
not.  TimBL says if they used terms from the OWL namespace, they are
using the OWL semantics; they committed to the OWL entailment of
whatever they said.  But you say otherwise, I think.  Unfortunately,
in saying otherwise, I think you're saying we don't have language
modularity in RDF/XML either.    Which is bad.....

Received on Monday, 21 July 2003 17:50:29 UTC