Re: rdf:value and RDF Schema (was: typed containers in RDF Schema)

>Frank,
>
>Oh, this is getting curiouser! More below...
>
>----- Original Message -----
>From: "Frank Manola" <fmanola@mitre.org>
>To: "Garret Wilson" <garret@globalmentor.com>
>Cc: <www-rdf-comments@w3.org>; "Brian McBride" <bwm@hplb.hpl.hp.com>
>Sent: Tuesday, June 11, 2002 11:31 AM
>Subject: Re: rdf:value and RDF Schema (was: typed containers in RDF Schema)
>
>
>>  You're
>>  interpreting the RDF Schema as necessarily defining *redundant*
>>  information that you can check for consistency against the instances
>>  (e.g. that if dc:creator has a range of Person, the resource that's the
>>  value of a dc:creator must have a rdf:type property with value Person),
>>  but technically the Schema can be equally interpreted as being
>>  additional descriptive information about instances (so if you find a
>>  resource that's the value of a dc:creator, you can assume it's of type
>>  Person because the schema says it must be).
>
>Oh, my. You're saying that RDF Schema is descriptive rather than
>prescriptive! Heavens (quoting a good friend of mine)!
>
>So my RDF Schema processor gets a canonical RDF Schema for "foo:" (it just
>knows which one to use---we all can accept that step, I think)

Not me. How does it know? RDFS is written in RDF, and the whole point 
of RDF is that information can be combined from nay number of 
sources. So the very idea of there being a single 'canonical' RDF 
Schema seems wrong-headed. If more than one RDF Schema document uses 
the same vocabulary, then they have equal status as far as RDFS is 
concerned. Of course, your application might have its own reasons for 
deciding that one of them is authoritative and the other not, but 
that decision lies outside RDFS.

>, and the RDF
>Schema says that the rdf:range of dc:creator for foo:Publication is
>foo:Person. I then feed the following RDF instance into the RDF procesor:
>
><foo:Publication>
>   <dc:creator>
>     <rdf:Bag>
>       <rdf:li rdf:resource="urn:x-people:jane-doe/>
>       <rdf:li rdf:resource="urn:x-people:john-smith/>
>     </rdf:Bag>
>   </dc:creator>
></foo:Publication>
>
>If you'll read my previous "typed containers in RDF Schema" posts (which
>assumed RDF Schema to be prescriptive), I had thought that the problem would
>be that the RDF instance above would be invalid---it couldn't see that the
>*members* of the rdf:Bag object of dc:creator contains Persons.
>
>Now, with a *descriptive* RDF Schema, it gets worse---the RDF Schema says
>that, whatever you might think about this RDF instance, the rdf:Bag is
>really of rdf:type Person.

Right, that is what it says. But that seems to me to be kind of 
obvious. How else could it possibly be interpreted? You SAID that the 
range of the property was foo:Person, and then you SAID that the 
value of the property on something was a bag. It follows inexorably, 
from the usual meaning of 'range', that you have said that the bag is 
a foo:Person. If you didn't mean that, why did you say it?

One could take the position that rdf:Bags ought to be 'transparent', 
so that their use as property values indicates that the 'actual' 
value is some combination of the members of the bag. The problem is 
in deciding on what combination to use. Does it mean one of them, or 
all of them, or some number of them, or what? There is no single, 
canonical semantics for transferring a property from a bag to the 
elements of the container. And in some cases one does in fact want to 
say that the bag itself is the property value, as in listing the 
members of a committee, say. So what can the RDF spec do, other than 
hand over responsibility to the particular application?

>With each correspondance, I think I'm understanding RDF Schema more and
>more---and seeing its utility less and less...
>
>>  Depends on the Schema processor, because once again, you're assuming a
>>  particular interpretation of these additional schema declarations.
>
>Darn interpretations! Hey, I have an idea: why doesn't someone invent a
>description language that would unambiguously encode semantics that would
>only be open to a single interpretation? ;)

That would be a great idea, but unfortunately Godel and Tarski proved 
that it couldn't be done, somewhere around 1940.

Pat Hayes

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Tuesday, 11 June 2002 18:31:38 UTC