- From: patrick hayes <phayes@ai.uwf.edu>
- Date: Fri, 14 Jun 2002 20:41:13 -0500
- To: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Cc: w3c-rdfcore-wg@w3.org
>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