Re: RDF Issue rdfs-clarify-subClass-and-instance

graham wideman wrote:

> Frank:
> 
> Again, thanks for taking the time to try to wade through this.  


No problem.

 
> 
>>But the rules don't say what you must do with this information.
>>
> 
> I completely accept this.  I believe it when you say that RDF does not prescribe that rdfs:domain information to be used as constraints.  This is *not* the issue.
> 


I know that's not the issue.  When I said "the rules don't say what you 
must do with this information", I was referring to *all* the information 
in the expanded graph, *including* the additional triple

ex:Garfinkle rdf:type ex:Book

added by the entailment.


> The issue is that RDF docs say that rdfs:domain *may* be used by an app that wishes to use them to establish constraints.  I believe that the semantics of rdfs:domain as prescibed by RDFS are such the it *cannot* be used for constraints.
> 


I understand that this is the issue;  I understood it the last time too, 
but clearly my answer didn't convince you that I did (my bad), so I'll 
try again.

The sticking point seems to be the rule rdfs2 in the Model Theory, which 
says:

if E contains:
     xxx aaa yyy
     aaa [rdfs:domain] zzz

then add:
     xxx [rdf:type] zzz

and, applying this to our example, this seems to say:

E contains:
     ex:Garfinkle ex:author "John Smith"
     ex:author rdfs:domain ex:Book

so we *must* add:
     ex:Garfinkle rdf:type ex:Book

Emphasis above on the *must*.  That is, your concern is that the rule 
seems to mean that your application is *required* to conclude that 
Garfinkle is a Book;  and as you put it later:

"at the point where it receives "Garfinkle has an Author property", the 
app is looking at an RDFS collection of facts where RDFS rules have
already concluded that Garfinkle is a Book"

(and so possibly the app can't figure out which information was 
originally there and which information was added by the RDFS rules?)

Anyway, this isn't what the rule means (and it's not the way things 
work).  The Model Theory (I hope Pat will correct me if I'm wrong about 
this) isn't saying that you necessarily actually construct this extended 
graph;  it's using this extended graph as a way of talking about all the 
information you have available, given an RDF graph and the schema 
information that describes the vocabulary used in that graph.  What you 
do with that information is a separate issue.  However, this way of 
describing things represents a particular "direction" of reasoning, and 
rather than keep going along these lines, it might be better to take a 
different tack, because I think the Model Theory explicitly addresses 
this issue.

Specifically, Section 4.3 of the Model Theory talks about the 
consequences of doing these entailments, and says the following:

"For example, one view of domain and range assertions is that they 
should be viewed as *constraints* on the legality of assertions 
involving a property.  On this view, the rules rdfs2 and rdfs3 would be 
most naturally seen as applying backwards, and rdfs2 would be better 
phrased as 'If aaa [rdfs:domain] zzz, then if xxx is NOT [rdf:type] zzz, 
then xxx aaa yyy is illegal', and similarly for rdfs3.  However, this is 
the same inference, differently phrased, as that expressed by the rule 
in the table above."  [Note the remainder of Section 4.3 as well].

Applying this alternative phrasing of rdfs2 to our example, the rule says:

if ex:author rdfs:domain ex:Book
then if ex:Garfinkle is NOT rdf:type ex:Book
then ex:Garfinkle ex:author "John Smith" is illegal.

I think this sounds like the kind of behavior you want, right?  However, 
note that the model theory says that this is *the same inference* as the 
earlier one, not an *alternative* inference.  Note also that the second 
line says *if* ex:Garfinkle is NOT rdf:type ex:Book, then the instance 
is illegal.  In the instance data in the original example, we had:

ex:Garfinkle rdf:type ex:Cat
ex:Garfinkle ex:author "Fred Smith"

We have no explicit data that says that Garfinkle *isn't* a Book, and we 
have no data that says that Cats can't be Books too.  So if the 
application takes the Schema definition

ex:author rdfs:domain ex:Book

and says that the above instance data is illegal, it must be choosing to 
believe that

ex:Garfinkle is NOT rdf:type ex:Book

based on some additional assumptions, e.g., that an instance is only of 
some type if the instance data explicitly says it is (and some 
additional assumptions about whether, given a collection of instance 
data describing some resource, like ex:Garfinkle, the application 
necessarily has *all* such instance data, to exclude the possibility 
that there is another triple ex:Garfinkle rdf:type ex:Book lurking 
somewhere else on the Web).  An application is perfectly free to choose 
to believe that Garfinkle isn't a Book in this case, based on whatever 
assumptions it wants to use.  The point is that RDFS itself isn't making 
that decision;  your application has to do that.  RDFS only goes as far 
as saying (using the original "direction") "look, based on the 
information I have here, Garfinkle must be a Book" or (using the second 
"direction") "look, based on the information I have here, *if* Garfinkle 
isn't a Book, there's a problem."  These are different ways of saying 
the same thing.  Your application still has to decide what to do about 
the situation.

Does this help?

--Frank




-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Friday, 30 August 2002 17:08:23 UTC