Re: a test case for "literals must be self-evident"

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