Re: new semantics initiative

>At 07:54 11/06/2002 -0700, R.V.Guha wrote:
>
>>Brian,
>>
>>  Sorry, but the approach described in the MT document currently up 
>>on the W3C site does *not* address the layering problem.
>
>In a rush.  Will answer at more length later.  I feel I'm hearing 
>different things from you and Pat.

Sorry, too many voices speaking at once. Guha and I agree on all the 
essentials.

>Are the semantics exactly the same or not.  BTW, Peter PS doesn't 
>believe this will solve the layering problem on the basis of what we 
>have seen so far.  Sorry this is rushed.  Don't have good email 
>comms at the moment.  My bad; should have been around just before 
>f2f.  My bad.

My bad too. Let me try to address your concerns.

(1) Why now?
A: Because, frankly, if we don't include something about this in the 
official RDF 'bundle' of documents, then it won't be seen as 
'official' RDF, and that will make it much much harder for it to be 
accepted. The output of this WG is going to become set in stone for 
ever, and we feel it is critical to get at least a reference to Lbase 
into the product of the RDF core WG.

It would have been better if this had been done earlier, I concede, 
and this is partly my fault, and so I would ask the WG (and it 
esteemed Chair in particular) to please not rule it out of scope, 
even though I know this is asking a lot at this stage.

(2) Are the semantics the same?
A: Yes, the plan is that they will be. (Peter is right that Lbase 
does not of itself solve the immediate layering snag, but read on. ) 
The idea is to arrange things so that the semantics are exactly 
equivalent, and that it - the semantics which can be described either 
way (see diagram in last section of 
<http://tap.stanford.edu/SemanticWebSemantics.html>http://tap.stanford.edu/SemanticWebSemantics.html 
) - has a built-in solution to the layering snags. This will require 
a very small change to the MT (read on.) There are in fact two 
proposals here, therefore, and we havn't said anything yet about the 
layering-fix proposal because we wanted to get Jonathan Borden's 
reaction first; but time is running out, so here goes. (Jonathan, you 
there??)

The way of dealing with the layering snag is to adapt the 
dark-triples idea (I will avoid 'dark' from now on) in a way that 
avoids the potential non-monotonicity. The thing that is potentially 
nonmonotonic is allowing an RDF graph to assert (in RDF or in OWL) 
that some vocabulary is supposed to not be asserted. So we don't do 
that: instead, we (ie the RDF coreWG) assume that the W3C will 
eventually have the good sense to declare that a certain namespace is 
*globally* understood to be 'rdf-invisible', in that any triples 
which use urirefs from that namespace are not asserted in any RDF 
graph. (Bear with me, OK?) We do this by tweaking the MT document, 
essentially by putting back the 'unasserted triples' stuff, although 
re-written to refer to a 'reserved namespace'. No other changes need 
be made to the RDF documents, except maybe some words of explanation 
in the Primer, since none of the other docs will actually use this 
hypothetical reserved vocabulary, and because the syntax will be 
unchanged.  Will the W3C actually do this? Hmmm, well, lets just say 
that there is a reasonable chance that they will. But in any case, 
suppose they don't; The worst that can be said is then that the RDF 
spec has some redundant stuff in it. None of it will be *wrong*. In 
any case, we can phrase the documentation to allow for the 
possibility, and that, I suggest, is all that the core WG needs to 
do.  That *provides* for other extensions of RDF (such as OWL) to 
encode non-asserted structure in RDF graphs/triple-stores, and it 
*mandates* the general form of the mechanism and the appropriate 
terminology to be used to do that, but it doesn't go into particular 
details because, frankly, that isn't the coreWG's business, any more 
than telling people what to put in their RDF graphs is the our 
business.

Let me emphasize how small this change to the MT actually is. The 
RDF-in-Lbase draft already incorporates this idea by using the words 
"where neither S, A nor T are in the reserved vocabulary of RDF" . 
That is the only change required to switch this on or off. (OK, so we 
also need a paragraph explaining what we mean by 'reserved 
vocabulary'. But really, no problem.)

(3) If that solves the layering issue, why do we need the other semantics?
A: Well, that solves it in the sense that it removes the immediate 
deadlock and allows WebOnt to get on with things (and pretty much in 
the way that Webont requested that RDF resolve it). But actually 
getting layering *right* is still a hard problem; and the point of 
the Lbase proposal is to try to help make that a lot easier in 
general.  So there is an independent motivation for the 
Lbase-semantics idea. Also see answer to (1)

(4) Do we have time to get into this, and will it divert effort from 
work on the MT??
A: First, to be blunt, Guha and I are going to write this thing no 
matter what the WG says or does, so diversion of (my) effort isn't 
really the issue :-) . But also, having the RDF-in-Lbase document 
handy will actually make the MT easier to write and also, I think, 
easier to read for many people. The two approaches in many ways 
support and illuminate each other.

BTW, we produced those document drafts in a hell of a rush, while I 
was travelling. I plan to rewrite the RDF-in-Lbase to be much more 
'visibly' parallel to the MT, and provide an appendix which sets out 
the correspondence in tabular form. There are also a couple of 
genuine bugs in it which will be fixed shortly.

(5) Does this require new liaisons between Webont and RDFcore, taking 
even more time?
A: No. If the coreWG includes an Lbase document and Webont decides 
not to, then that will be Webont's decision. I think this is very 
unlikely to happen, but it would not be a disaster even if this 
entire proposal died the death after RDF was finished: the 
RDF-in-Lbase document would still be a useful resource for many users 
and implementors.

(6) Does this require any changes to syntax/ test cases/ Ntriples/ 
datatyping/ whatever?
A: No.

Pat




-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes