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


Comments below.

graham wideman wrote:

> Frank:
> Sorry I didn't realize your were understanding my point in previous email, but nice to hear that you do.
> Sounds like at this point you concur that *if* the RDFS-processing portion of the app is *required* to "execute" rdfs2-forward (and thus add "Garfinkle is a Book") *then* this defeats the ability to use rdfs:domain as part of constraint checking. Good.

Sorry, but I don't agree.  That the RDFS in this case says that 
Garfinkle is a book is one thing;  that much I agree with.  That this 
defeats the ability to do constraint checking, I don't agree with.  I 
think you're reading too much into this "addition" of "Garfinkle is a book".

> But you make the very interesting assertion that RDFS in fact *doesn't* say that this input must be interpreted this way, and point to the discussion in MT 4.3 as support.
> I must say, I had read MT 4.3 and was sufficiently unable to make sense of it that I assumed that it had gotten disrupted in editing. I genuinely don't understand what this paragraph means:
>>"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." 
> "the same"? What's the same? We have:
> Forward: Instance Garfinkle appears with an author property. Books have author. Therefore Garfinkle is a Book.
> Backwards: Books have author. Garfinkle in not a Book. Therefore "Garfinkle has author" is illegal".

First of all, you missed an "if" in there.  Backwards says *if* 
Garfinkle is not a Book, then Garfinkle has author is illegal. 
Backwards doesn't itself conclude that Garfinkle is not a Book; the 
application has to make this determination based on additional 
assumptions it's making.

> In once case Garfinkle is legal, in the other he's not. Employing one view the receiving system accepts the data (and places Garfinkle in a particular class to boot!); employing the other it rejects the data.  Of course there are even other paths that an app *could* take, like assuming that Cats have authors.

These are not alternative views of what the RDFS says;  they are more 
like alternative ways of putting it, both of which really mean the same 
thing.  In doing any kind of validation against a schema, you're taking 
what the schema says, looking at it together with what the instance data 
says, and trying to detect what appear to be inconsistencies.  In this 
case, the schema has the triple ex:author rdfs:domain ex:Book.  The 
result of taking this together with the instance data can be read in two 
ways, which actually say the same thing:

1. "forwards" says "based on the information I have here, Garfinkle is a 
Book [because Garfinkle has an author property]"

2. "backwards" says "based on the information I have here, *if* 
Garfinkle *isn't* a Book, there's a problem [because Garfinkle has an 
author property]"

In neither case does the schema "decide" what to do (it doesn't know 
whether there's a problem or not).  What your application does is use 
the additional information provided in (1) or (2) to decide what to do.

In (1) it takes the inference "Garfinkle is a Book" and tries to decide 
whether that's reasonable or not.  What you're saying you want is that 
the app uses that as a basis to conclude that the instance data is wrong 
(because it has other information or is making other assumptions that 
cause it to decide that "Garfinkle is a Book" can't be correct).

In (2) it has to evaluate the "if-then" condition "if* Garfinkle *isn't* 
a Book, there's a problem".  In effect, this involves doing the same 
thing as in (1);  it has to consider the statement "Garfinkle is a Book" 
and decide whether that makes sense or not.  What you say you want is 
for the app to say "that doesn't make sense", hence Garfinkle isn't a 
Book, and hence "there's a problem".

In both these cases, your app is taking the additional information 
provided by the schema, and using that information in some appropriate 
way.  But all the Schema does is provide this additional information 
(about domains, in this case).  It's not telling your app how it has to 
use it.  I understand that you want something more prescriptive.  But 
right now, let's get straight that the specs *do not preclude* you from 
using the Schema information to enforce constraints.  Specifically, the 
specs do not require your app to decide that Garfinkle is a Book in this 
case.  The specs say that's an additional inference that follows from 
the Schema declarations and the instance data, but they don't say your 
app can't say "well in that case the instance data must be wrong, 
because this conclusion is inconsistent with what I know (from other 

> If the goal of RDFS is to facilitate sharing of information, then surely RDFS has to specify the semantics here. Otherwise it's up to individual system developers to negotiate with each other, which completely undermines RDFS even bothering with a Schema.
> I therefore thought that the rules were a prescription.  If they are not a prescription, then what's the point?

The rules are a prescription of what the RDFS declarations mean, but not 
on how the combination of the instance data and the information in the 
Schema have to be used.

> For what it's worth, the Primer (2002-08-23) states emphatically: "any resource that has an ex:author property is an instance of class ex:Book", and reinforces this in the subsequent paragraph that this can lead to unexpected situations. The Primer does *not* say: "if you wish, your application could infer class from property, or it could check whether this property is permitted on the class that the instance claims to belong to" (and then point out the interoperabilty issues *that* would lead to!).

The Primer says "This [the statement ex:author rdfs:domain ex:Book] is 
an RDF statement that...(c) any resource that has an ex:author property 
is an instance of class ex:Book." That's what the schema information in 
this case says, not what your app must ultimately conclude.

> The presumably normative document on this, "RDF Vocabulary Description Language 1.0: RDF Schema" (2002-04-30) is rather ambiguous on this subject, refering to the MT.
> Concrete Cases
> --------------
> To put it another way, do the following examples say that Wealth or Nations is a Book written by Adam Smith in a way that every RDFS-savvy reader agent will accept?   Ie: is the rdf:type optional while still guaranteeing that all readers will regard the instance as a member of Book? 

My answer would be "no".  That is, example 1 explicitly says that Wealth 
of Nations is a Book, and an RDFS-savvy agent has to accept that (that's 
what the RDF says).  In example 2, an RDFS-savvy agent could reasonably 
say, in effect, "this instance has an author property, and according to 
the schema it must be a Book;   but it doesn't explicitly have a type 
property saying it's a Book, and my operating instructions are to reject 
such instances as ill-formed".

> Example 1:
> ----------
> <rdf:Description rdf:ID="Book">
>   <rdf:type rdf:resource=""/>
>   <rdfs:subClassOf rdf:resource=""/>
> </rdf:Description>
> <rdf:Description rdf:ID="author">
>   <rdf:type rdf:resource=""/>
>   <rdfs:domain rdf:resource="#Book"/> 
> </rdf:Description>
> <rdf:Description rdf:ID="title">
>   <rdf:type rdf:resource=""/>
>   <rdfs:domain rdf:resource="#Book"/> 
> </rdf:Description>
> <rdf:Description rdf:ID="1234">
>   <rdf:type rdf:resource="#Book"/>
>   <ex:title>Wealth of Nations</ex:title>
>   <ex:author>Adam Smith</ex:author>
> </rdf:Description>
> Example 2:
> ----------
> Same except for the instance:
> <rdf:Description rdf:ID="1234">
>   <ex:title>Wealth of Nations</ex:title>
>   <ex:author>Adam Smith</ex:author>
> </rdf:Description>
> --------------------------
> At the moment I don't see how RDFS can *avoid* taking a position on whether apps must infer class from property if RDFS expects to facilitate communication. (And of course, I think they should not make this inference, because it undermines the point of Schema.)


The problem with this is that "facilitate communication" is left totally 
open.  That is, this seems to be saying that if RDFS doesn't prescribe 
that RDFS declarations should be interpreted in a specific way, it can't 
facilitate communications at all.  I don't think that's true. 
Certainly, in this case, the Schema facilitates the communication of the 
information that "the guy who wrote this schema thinks books have 
authors".  In any event, let's try to settle one question at a time.  In 
this case, the app "must infer class from property" to the extent that 
I've described it above.  Given the schema and an instance with 
properties, the app must consider the implications of that information 
(if the app didn't draw any inferences, it would be unable to enforce 
any constraint it wanted to enforce, e.g., that there was a conflict 
between what the schema said and what the instance said).  However, the 
app is *not* required to give that schema-derived information any 
particular "weight", compared to other information it has (either as 
explicit information, or built-in "knowledge").


Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420       voice: 781-271-8147   FAX: 781-271-875

Received on Monday, 2 September 2002 16:51:47 UTC