Re: the idea of a 'reserved' vocabulary

>The broad thrust looks good to me.  I have a couple of comments - 
>one nit and one more substantive.
>
>At 07:08 PM 6/13/02 -0500, patrick hayes wrote:
>
>>Here's a rough draft of what Id like to say in the RDF MT document 
>>about 'reserved' (we don't say 'dark' these says) vocabulary, to 
>>give you an idea of what is being proposed here.
>>
>>------
>>What does it mean to assert an RDF graph? The normal answer is that 
>>each triple can be read as a simple proposition, and the graph as a 
>>whole represents the conjunction of all of these propositions, so 
>>that what is asserted is the content of all the triples in the 
>>graph. Asserting a triple amounts to saying that it is true, and 
>>what that means, in turn, depends on what defines the meanings of 
>>the terms used in the graph. Before discussing that in more detail, 
>>we first note that it is also possible to use RDF triples simply as 
>>a data-structuring mechanism for encoding expressions of other 
>>languages which have a more complex syntax. If those 'encoding' 
>>triples are regarded as assertions in the same way as other 
>>triples, complexities can arise because the meaning they would have 
>>when seen simply as RDF assertions might not correspond to their 
>>intended interpretation in the other language. To accommodate such 
>>encodings and avoid these complications, we allow that some urirefs 
>>may be declared to be 'reserved'. Triples using urirefs from any 
>>reserved vocabulary can be present in an RDF graph but do not 
>>themselves make any RDF assertions. They may, however, be part of 
>>an encoding of expressions in some other language which itself may 
>>be asserted by the RDF graph in question, according to the semantic 
>>rules of that other language. We note that an RDF parser or 
>>processor is not required to treat such triples in any special way,
>
>Nit:  add "(other than that any such triples not having any affect 
>on the truth or entailments of a graph)" or something like that.

Hmm. Actually I meant it to be taken seriously. Suppose an RDF 
inference engine just ignores this issue entirely and draws some 
rdf-valid conclusions from a set of triples which uses a reserved 
vocabulary. If the conclusion itself contains the reserved 
vocabulary, then it is harmless.

There is an issue about the possibility of a conclusion being formed 
by existential generalization, but we can fix that by requiring that 
its the property uriref that determines whether a triple is made 
'invisible'. That is slightly more restrictive, but I think it will 
be enough for all the uses anyone is likely to want to make of this. 
Eg it would cover a list-like container vocabulary.

>
>>unless it also needs to access the content expressed in that other 
>>language encoded in an RDF graph.
>>
>>Since reserving a vocabulary effects the meaning of RDF, the 
>>authority to declare a uriref or urirefs 'reserved' in this sense 
>>rests with the W3C.  A uriref or set of urirefs is reserved only if 
>>it is declared to be so by a W3C Recommendation. In particular, 
>>reserving a vocabulary cannot be done by simply asserting on a 
>>webpage that it is to be considered reserved. There is no way to 
>>state in RDF, or any language encoded in RDF, that a uriref is 
>>reserved, or for any RDF document to entail this as a consequence.
>
>My more substantive comment:  some folks are going to have to 
>implement this stuff, and the above statement doesn't really help 
>them.  Therefore, I think the spec should state up-front the form of 
>URIs that won't be asserted.  To alleviate the issues of 
>URI-inspection, I think we could limit the form to something like:
>
>     http://www.w3.org/2002/06-rdf-unasserted#<foo>
>
>where values of <foo> must be documented in W3C recommendation track 
>documents.  Effectively, this designates a single URI for dark 
>triples, for which there will be a single associated schema document 
>listing the URIrefs whose use suspends statement-assertion.

I would be happy with that, provided that future W3c specs can add 
new <foo>s. At this point this is a W3C procedural issue, not a 
technical one, I guess.

Pat



-- 
---------------------------------------------------------------------
IHMC					(850)322 0319   cell
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax

Received on Friday, 14 June 2002 21:41:13 UTC