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

Frank,

First, thank you and the others so much for your responses.

Actually, I am getting more worried about RDF and especially about RDF
Schema.

As I mentioned to Patrick Hayes offline, <quote dc:creator="##self">I assume
that, given an RDF Schema,

1) A visual RDF instance editor would be able to constrain the allowed
object values to match those allowed in an RDF Schema, and,

2) A processor (e.g. software or a human) would be able to take any given
RDF instance and determine if it meets the constraints (er, assertions)
present in the RDF Schema.

If those two things can't be done, what's the purpose of RDF Schema?</quote>

I'm getting the idea that these two things *can't* be done for any use case
except the most uninteresting ones.

More responses:

----- 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 10:03 AM
Subject: Re: rdf:value and RDF Schema (was: typed containers in RDF Schema)


> The problem is that in your "Jane Doe" example the b-node is supposed to
> be something of type Person (since it's at the end of the dc:creator
> property), and the rdf:value property of that "something" is supposed to
> be the actual Person you're talking about (as if you'd said, in some
> logic notation, (exists x) creator(book1,x) and
> x=urn:x-people:jane-doe).  In this case, you'd want the semantics of
> rdf:value to be something like "is the same resource as", but it really
> isn't defined that way...

Right. I want the object of dc:creator to be of rdf:type Person. From what
you say, a b-node will *not* be of rdf:type Person, even though it has an
rdf:value object that is of rdf:type Person. This makes RDF Schema useless
for objects that have "contextual values".

Before, I was seeing a b-node with an rdf:value as similar to an internal
anonymous Java class---an instance of a type that automatically gets all its
properties, but allows its own local properties. In this case, there is no
inheritance involved, so perhaps a better analogy would be creating an alias
of an RDF class instance and assigning properties to that. From what you
say, it appears that this is incorrect---there really is no formal semantics
for what is going on. Again, this makes RDF Schema almost useless for these
cases.

Furthermore, it makes rdf:value almost useless as well. Rather than relying
on RDF semantics for rdf:value, I have to apply special semantics for
rdf:value in the context of my specific vocabulary---something I could have
done with a *custom* property such as custom:aliasedResource.

> In fact,
> the definition of RDF Schema (both the original version and the current
> version) says that how an application or schema processor uses the
> information contained in an RDF Schema depends on the application.

How the schema processor *uses* the information, perhaps (that is, whether
and how a processor "accepts" or "rejects" a document), but I would think
that how the information is semantically *interpreted* would be unambiguous.
If there is no formal semantics of which RDF instances comply with which RDF
Schema instances, then however could one find RDF Schema useful other than
as an informal documentation tool? Why not call it "RDF Annotation," or,
"RDF Give You a Rough Idea of Schema But Use Your Own Intuition As Needed?"

(Please excuse the sarcasm as I slowly become more disillusioned... ;) )

> Second, if you wanted to do strict validity checking and have this
> example pass, you could always add an rdf:type property having a value
> of type Person to the b-node, right?

Right, but oh, that would confuse an RDF Schema Processor to no end---if the
b-node is explicitly declared to be of type Person, what about all the
constraints on Person that would not be present in the b-node? If the RDF
Schema Processor doesn't impute a type of Person on the b-node through
rdf:value, thereby imputing to the b-node all the properties of the
rdf:value as well, then this would just be a mess...

> Third, just because rdf:value has no *formal* semantics in RDF doesn't
> mean it doesn't have *informal* semantics.

Again, this sounds useless---I could create my own custom:property with real
formal semantics---why use ambiguous undefined informal semantics of
rdf:type? The whole point of RDF is to be semantically concise and
unambiguous, right?

> Offhand, it's hard to think of a way to convey the
> general idea formally, because its interpretation varies from case to
> case.

Ackkk, this is the exact reason I've been evangelizing for RDF with all my
clients---that they would never again have to hear a sentence like that!

> Note also that these informal semantics of "main value" for
> rdf:value are not the same as the (approximately) "same resource as"
> semantics for rdf:value used in the Jane Doe example.

So in summary, I'm getting two feelings (undefined, informal feelings ;) )
from all this:

1. I'm using rdf:value incorrectly---it doesn't mean that it is the value of
the b-node, but it means that the b-node is a composite of several values,
and somehow the rdf:value portion should be marked as the "main" one. This
means that I should *not* use b-node/rdf:value for:

  a. Expressing a contextual oebps:role for a dc:creator value.
  b. Expressing a contextual dc:title for an xmlprop:stylesheet value.
  c. Expressing a contextual oebps:file-as for a dc:creator.

(All of these are immediate needs, but it seems as if RDF can't accomodate
them.)

2. RDF Schema should not be used to formally represent the way an instance
should be constructed or constrained---it's at best a fuzzy-wuzzy feeling of
how one might string together a set of statements.

Oh.

And after finding out that rdf:Seq is not really a sequence, and that
rdf:Alt is not an alternate, and that RDF Schema can't talk about ranges of
alternate values or bags of values, I'm getting a little disillusioned...

Garret

Received on Tuesday, 11 June 2002 13:43:44 UTC