- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Thu, 13 Dec 2001 03:41:38 +0000
- To: Dan Connolly <connolly@w3.org>
- Cc: Pat Hayes <phayes@ai.uwf.edu>, w3c-rdfcore-wg@w3.org
At 02:02 PM 12/10/01 -0600, Dan Connolly wrote: >For example, take: > ><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:dc="http://purl.org/dc/elements/1.1/" > xmlns:ex="http://example/vocab#"> > <rdf:Description rdf:about="http://www.w3.org/"> > <ex:orgDirectorShoeSize>10</ex:orgDirectorShoeSize> > </rdf:Description> ></rdf:RDF> > >now one minute, I get some schema info from >http://example/vocab that says the range >of ex:orgDirectorShoeSize is a numeral. >I parse that into my knowledge base, then I parse >the document above. In the P++ scheme, the >object of the triple I get from parsing is an integer, >if I understand correctly. > >The next minute, somebody edits the example vocabulary; >I restart my program and grab the schema; now >it says the range of ex:orgDirectorShoeSize is numeral >(a string constrained to [0-9]+, say). Then I parse >the above document again. Now the object is a string. > >So I've parsed the same document twice, and the two >formulas I got don't entail each other. My intuition about this is that the schema statements cannot modify what you get by the simple action of parsing. When you parse your example, you get the graph: <http://www.w3.org/> ex:orgDirectorShoeSize "10" . The existence of some schema doesn't affect the result of parsing. Under the P/P++ schemes, it *may* affect the interpretation of the graph obtained by parsing. When you talk about entailment, I think any schema statements that are being used to restrict the possible interpretations must be considered to be part of the graph. So, consider three possible graphs: (a) <http://www.w3.org/> ex:orgDirectorShoeSize "10" . (b) <http://www.w3.org/> ex:orgDirectorShoeSize "10" . ex:orgDirectorShoeSize rdfs:range ex:integer . (c) <http://www.w3.org/> ex:orgDirectorShoeSize "10" . ex:orgDirectorShoeSize rdfs:range ex:numeral . where: (a) is what you get from the document considered in isolation, (b) is what you get from the document merged with one schema, and (c) is what you get from the document merged with a different schema. Now, I think it's pretty clear that: (a) entails (a) (b) entails (b) (c) entails (c) but that: (a) does not entail (b) (a) does not entail (c) (b) does not entail (c) (c) does not entail (b) It's less clear that: (b) entails (a) (c) entails (a) The final two cases are the "interesting" cases for P/P++; as I recall the proposals, those entailments do work because the effect of the proposals is that the added schema datatyping information has the effect of restricting pairs in the relational extension of ex:orgDirectorShoeSize in models; i.e. for all models of... (a): IEXT(I(ex:orgDirectorShoeSize)) contains: <I(http://www.w3.org),integer(10)> <I(http://www.w3.org),numeral("10")> (and others) (b): IEXT(I(ex:orgDirectorShoeSize)) contains: <I(http://www.w3.org),integer(10)> (c): IEXT(I(ex:orgDirectorShoeSize)) contains: <I(http://www.w3.org),numeral("10")> which, from the model theory definition of truth for a statement, leads to the entailments noted. In conclusion, I see no reason to say that a document does not entail itself under P/P++. #g -- ------------------------------------------------------------ Graham Klyne MIMEsweeper Group Strategic Research <http://www.mimesweeper.com> <Graham.Klyne@MIMEsweeper.com> __ /\ \ / \ \ / /\ \ \ / / /\ \ \ / / /__\_\ \ / / /________\ \/___________/
Received on Wednesday, 12 December 2001 23:49:14 UTC