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

Frank:

Thanks for your detailed comments. You've at least not alerted me to something that I had completely missed!   Now to the two issues under consideration:

1. The "Property implies class" Problem
----------------------------------------
Much of what you (and various RDF docs) say about the impact of rdfe:domain is along the lines of:

>we're not *forcing* resources to become instances of classes by making
>rdfs:domain declarations;

... suggesting that my private app could regard the rdfs:domain statements any way it likes, in particular that it can employ the rdfs:domain and related features to support the constraints that I outline.  

But your assertion ("not forcing") seems incompatible with what the docs say. The latest Primer, I now see, is in line with the Model Theory (2002-04-29) doc section 4.2, which provides rule rdfs2:

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

then add:
  xxx [rdfs:type] zzz

To me this says that if I claim that my app is using ("conforming to") RDFS, then it has to abide by this entailment. So, when I get to your example:

> ex:author rdfs:domain ex:Book
>
> ex:Garfinkle rdf:type ex:Cat
> ex:Garfinkle ex:author "Fred Smith"
>
> [... must the app conclude the following?...]
> ex:Garfinkle rdf:type ex:Book

> your processing application could say a number of things:
>
>1.  The instance data must be wrong:  Garfinkle must be a Book rather
>than a Cat
>2.  The instance data must be wrong:  we'll say that it's invalid
>3.  The schema must be wrong:  Cats can clearly have authors too
>4.  Everyone's right:  Garfinkle is both a Book and a Cat

... I believe that the RDFS entailment above requires my app to decide 4, "Garfinkle is both a Book and a Cat" if it wants to claim compliance with RDFS. 

If you are saying that my supposedly RDFS-complying app is free *not* to abide by the entailment above, then what is the distinction between RDFS rules that are required, and RDFS rules that are not?  Perhaps my app could freely ignore subClassOf and rdf:type as well and still be an OK RDFS app?

2. The Multi-Class Domain Problem
----------------------------------
Thanks, you provided a nice explanation of how this arises as a result of:

a) The above "Property implies Class" semantics, and
b) Multi rdfs:domain statements are individual assertions which must all be individually satisfied.

I continue to regard the result as a fatal flaw, but it now strikes me as a secondary problem. 

FWIW, if the only problem were the need to be able to spec that a Property can apply to instances of *any* of a list of classes rather than *all* of a list of classes, surely RDF has available syntax that the Schema spec could employ for this? (Maybe ALT fits in here... I haven't thought it through other than to hope that RDF is capable enough that this simple matter would be trivial to cast in RDF(S)...)

3. "Property implies class": Revisited
--------------------------------------

In the real world we often (usually?) classify objects based on their "properties":

4-legs, furry, barks --> class = dog
4-legs, furry, meows --> class = cat
flippers, furry, barks --> class = seal 

It is a *special case* where we can determine class membership based on only a single property. 

Hence, IMO, RDFS's prescription that each single property determines class membership independent of other properties is significantly at odds with the real world objects that RDF is designed to talk about. 

I'm increasingly convinced that this leads to several consequences (already noted) that prevent use of rdfs:domain and related features as the basis of any useful functionality at all.

Here's what I'd need to convince me otherwise -- and I'm hoping that somebody can point me to docs where these were already thought through in the process of devising the rdfs:domain etc features:

a) rdfs:domain Applied Usefully: An example where rdfs:domain does record the specs necessary to support *any* useful non-trivial constraining of properties to instances of particular classes. 

b) An Important Example Implemented: An example where constraints for a couple of tables (in the database sense), are specified by rdfs:domain statements. Particularly where the tables have a field/property in common. 

Such use cases would really be proof of the pudding... or proof that there's at least some pudding!

Thanks again for your exchange!

(BTW, if we are at this point off the original Subject and should start another, feel free or let me know what the protocol is for doing so.  FWIW, this appears to relate to issue: rdfs-domain-and-range, but that looks rather stale and like it was left in an inconclusive state. Ie: the docs there seem to pre-date whatever thinking went into "closing" the issue)

Graham 

---------------------------------------------------
Graham Wideman
Resources for programmable diagramming at:
http://www.diagramantics.com
graham@wideman-one.com
http://www.wideman-one.com

Received on Thursday, 29 August 2002 06:17:12 UTC