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

Frank (because this is about the Primer) and Folks:

In continuing my stint as test reader of RDF docs (though I'm becoming less a virgin reader by the hour :-) ... a success and a serious setback to report...

1. Progress in Understanding, and Why
-------------------------------------
First, I feel that I'm making some solid progress firming up what RDFS is all about, certainly partly from the various emails that have been generated (thanks all!). In addition, particularly helpful was following the thread of messages following Frank's:

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Aug/0173.html

... which gave me some confidence that I can understand RDF as a system that can "stand alone" independent of RDFS.  More importantly it clarified that what RDFS adds is not just another namespace-worth of elements and their semantics, but also additional semantics for "already existing" RDF elements, notably rdf:type. 

In particular, it made sense out of doc statements like "rdf:type requires a value which is an instance of rdfs:Class".  I'm now seeing that this probably means something more like: "rdf:type requires a value which in RDFS would be regarded as an instance of rdfs:Class".

2. Showstopping Setback: rdfs:domain *can't* work like that, can it?
--------------------------------------------------------------------
In the process of firming up my understanding of RDFS's take on types, classes and properties, I've stumbled across what appears to be a 180 degree switcheroo between the current WD of the Primer (2002-04-26) and the Editors' WD (2002-08-23).  In fact, it's so conspicuous (and presumably reflects some well-discussed underlying change in RDF principles) that I almost feel stupid pointing it out, but:

Current WD section 4.2 says:     rdfs:domain specifies the classes' whose instances a particular property may be applied to. The text is clear that this feature is intended to support constraints.

Editors' Draft (newer) section 5.2 says:    rdfs:domain specifies that if an instance has a particular property, then it's to be regarded as belonging to the designated class. Furthermore, if the property has multiple domain classes, then an instance with this property is to be regarded as a member of *all* those classes. (The text of 5.3 say that this mechanism may be further interpreted by an application however the application likes, one possibility being as a constraint... but see below...)

Summary: 
Old: Class membership implies something about properties of instances
New: Properties of instance imply class membership

Now, suppose I want to use RDFS for the mundane task of specifying structure and data of a few boring tables. I initially think that I can use rdfs:domain as part of my specification of which classes can have which properties. 

The old tutorial would lead me to believe that I *might* expect an RDFS processor to understand the constraints and enforce them.  The new tutorial lets me know that enforcement of constraints is not within the scope of RDFS. OK, I have to provide the constraint implementation, but I at least see how I can use rdfs:domain to specify the constraints.

But, so far as I can see, according to the *new* tutorial, the RDFS-prescribed semantics of rdfs:domain basically *precludes* me from using rdfs:domain even as the *basis* for the constraints.

First of all, if RDFS *prescribes* that possession of a particular property implies membership in a particular class, then an RDFS processor is violating RDFS if it chooses to interpret the association the other way around as a constraint.  Ie: the constraint mechanism *can't* regard an incoming instance to be in possession of an illegal property, if by RDFS rules, the presence of that property automatically makes the instance a member of a class that *does* permit such a property! (Of course, if that property is not defined anywhere, an app could rule it illegal due to no definition -- but that's not employing an rdfs:domain constraint.)

Second, the multi-class domain seems a further insurmountable problem.  If, as in the tutorial's example, I happen to have one table (class) "Book", and another "MotorVehicle", and they both have a "weight" field (property), I don't appear to be able to specify this in RDFS without causing all records (instances) with a weight property to become instances of both classes.  Since the constraint I'd most obviously want to implement (in this tables scenario) is that each instance must have exactly a certain set of properties (fields) according to its class, the RDFS prescription ends up causing all instances to be required to have all properties -- obviously untenable.

Surely this can't be the intent?  

(a) It seems to preclude this mundane but bread-and-butter case

(b) I don't understand even the rationale for prescribing that class membership be deduced from properties. Why are we expecting RDFS instances to appear without an explicit indication of what class they belong to?

To take a different run at this: The text in 5.3 "Interpreting RDF Schema Declarations" goes to great length to tout the new emphasis on the *descriptive* orientation of RDFS, and the de-emphasis on the *prescriptive* orientation.  

So from April to August, we seem to have thrown out one of the features that you would *most* expect a thing called a "Schema" to provide  -- the ability to assert in a way that's understood consistently everywhere (even if not enforced) the association of particular properties with instances of particular classes.   Meanwhile, we have *added* some bizarre *prescriptions* that appear to prevent us from privately interpreting the rdfs:domain mechanism to support implementing constraints even within a particular application. 

So, at this point I'm a little dumbfounded, or maybe just reading this very wrongly... To say the least, I'm going to be fascinated by how this turns out!

Regards, and thanks again for the email exchange,

Graham






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

Received on Wednesday, 28 August 2002 10:15:17 UTC