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

(Frank: This is a duplicate: I had neglected to forward to group)

Frank:

Wow, this is impressive! I can't help feeling you are an intelligent person, and since I *think* I am one too, it's mind boggling to see how we're going around on this topic!

I think I *may* have some thoughts that will either reveal my "wrong thinking", or that will continue to trap this issue into a corner and reveal where the discrepancy is.

1. Open vs Closed set of data
-----------------------------
I have seen some time ago that in approaching constraints, RDF(S) faces a problem with not knowing whether it's seen an exhaustive (enough) chunk of data to know what the constraints should be.

You already know that what I'm looking for is to be able to say:

Class Book has property author
Class Cat  has properties X, Y and Z, but not an author property

In a traditional language or DB environment, when I declare a type or table, just the fact that I don't specify an author property for Cat means that it doesn't and can't have one.

But in the RDF case, if we may not have seen all the Property definitions relating to Class Cat, then by absence of 
Class Cat  has property author 
we can't assume that Cat has no property author.

Fair enough. So you would need more assumptions, such as: in order to interpret this bunch of data as having constraints, we *will* assume that we have seen all Schema info, and thus we *will* interpret the absence of ...

Property author domain Cat

to mean that Cat's having author property to be an error. The very desire to have constraints indicates that there's some proportion of use cases where we will indeed think we have a complete enough schema, and thus be happy with these assumptions.

I see this issue, but despite what you write I can't reconcile this interpretation with what I see as the docs assertion that "property implies class"... but maybe my next point sheds some light on this...

2. "Content" and "Schema" having different weight?
--------------------------------------------------

You comment:
> 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").

and you said (following my Adam Smith example) that 

i)  instance    Wealth Of Nations   rdf:type Book

...is NOT equivalent to...

ii)  Property   author  domain   Book
    instance    Wealth Of Nations   author   Adam Smith

so far as asserting that Wealth of Nations is a Book.  Reason: an app could treat inferences from Schema statements as lower weight than "direct" statements.

Whoa! This has me really puzzled, but maybe this is a key point. I *thought* that Schema statements were in a sense freely intermingled with "content" statements to the point where there was no distinction as to weight. Ie: the Schema assertions are just as much content as the rest of the content.

But what you're saying almost implies a processing model like:

As we read the incoming files, we assemble explicit content statements into one structure, and schema statements into another structure.  

Then, optionally, our app can "apply" the schema to the content, where "apply" could mean different things to different apps... either adding inferences, or detecting conflicts, or some combination.

I know there's much insistence that RDF does *not* get into the business of the processing model, but without some notion of processing a lot of this is a bit abstract.

Regardless, you seem to be asserting that facts derived via schema are of a qualitatively different nature than facts stated directly, yet the nature of this qualitative difference is not well illuminated (IMO) in the docs. Particularly since RDFS goes out of its way to avoide a strong distinction between the regular RDF statements and RDFS statements -- ie: there's no distict "meta" level, it's all "equally" descriptive.

So now let's see if this difference in weight is indicated in the docs...

3. Primer discussion
--------------------- 
In the Primer we have:

"This [statement (ii) above ] is an RDF statement that (a) ex:author is a property, (b) ex:Book is a class, and (c) any resource that has an ex:author property is an instance of class ex:Book."

Since this gives no clue that one or more of these is an inference that is less weighty, I have to think that this discussion in the Primer is incorrect.

In fact, if (ii) *is* an optional interpretation, then surely this section of the primer should read more like:

"Some apps may interpret domain so as to infer class from property, whereas others might use the domain info as a constraint. Developers should not use domain as a replacement for explicitly providing rdf:type info on their instances."

4. RDFS Constraint Example
--------------------------
I'm still looking for an example of RDFS Schema used for constraints in a non-contrived way. I've looked at:

OIL: no use of domain
RSS: no use of domain
Dublin Core: no use of RDFS as far as I could tell
PRISM: Makes little if any use of RDFS
XPackage: insignificant use of RDFS
CIM/XML: Very interesting, see note below
Gene Ontology: Doesn't mention RDFS

CIM is interesting in that it does present a use of rdfs including rdfs:domain, with rdfs apparently auto generated by Rational Rose?

This example appears to employ domain in such a way that the data at least could be used for constraints, but it does so by basically neutralizing the ability to have a same-named property on any two or more classes.  It does this by creating property names of the form:

classname.propertyname, for example

  Property Measurement.Unit domain Measurement

rather than simply 
  Property Unit domain Measurement

...thereby forcing every property name to be unique not just within class but within the namespace. 

I had rather arrived at the same conclusion myself.

By the way, this I believe eliminates any merit of defining properties separate from classes, making all of that extra counter-traditional scheme (including odd semantics for multi-domains) of no value.

But, in case I'm wrong, I'm still looking for an example that demonstrates how RDFS would say:

Class Book can have property Name
Class Cat  can have property Name

... and classes Book and Cat are otherwise nothing to do with each other.

=========================

Graham







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

Received on Wednesday, 4 September 2002 01:31:38 UTC