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

Brian,

----- Original Message -----
From: "Brian McBride" <bwm@hplb.hpl.hp.com>
To: "Garret Wilson" <garret@globalmentor.com>; <www-rdf-comments@w3.org>
Sent: Tuesday, June 11, 2002 3:52 AM
Subject: Re: rdf:value and RDF Schema (was: typed containers in RDF Schema)


> At 20:19 09/06/2002 -0700, Garret Wilson wrote:
>
> [...]
>
>
> >Well, let's say I have another work (urn:x-books:book2) that has the same
> >dc:creator of urn:x-people:jane-doe---but in this case, Jane is the
author,
> >not the annotator. If the b-node above is the same as
urn:x-people:jane-doe,
> >then there's a big problem: Jane Doe would be listed as the annotator of
> >urn:x-books:book2, even though she's the *author* of that work. That is,
> >once a non-b-node Jane Doe gets an oebps:role, she *always* has that
role.
>
> Just so and I thought that was why you had structured things this way.
How
> then how do we think of the type of that b-node.  If we think of it as
> "person-in-role" and "person-in-role" is a subclass of person, then the
> range constraint of the creator property is maintained and that is
> fine.  But then the use of rdf:value, whilst not wrong, since RDF defines
> no formal semantics for it, doesn't quite feel right to me.

Ooh, that's news to me. If there are no formal semantics for rdf:value, then
how would the given example pass an RDF Schema test that required a range of
&person;? (You say earlier,"An RDF schema processor won't barf on this; it
will simply conclude that the value of the dc:creator property has type
&person;)

> I'd have used
> a more specific property, e.g. person.

...but that's not what I'm wanting to say---the creator doesn't *have* to be
a person, it could be an automated tool or anything. What you're essentially
saying is that the b-node object of the dc:creator property should have its
own dc:creator property.

> I'm not arguing that your modeling is wrong; at this stage I'm just trying
> to understand it.

Well, one thing that possibly confuses you is that the contextual property
I'm trying to use is oebps:role, which makes you think that I should use a
subproperty. Ignoring oebps:role for a second, think back to the *other*
example I gave: a title for an XML stylesheet that is only valid in the
stylesheet's relationship to the XML document:

<rdf:Description rdf:about="urn:xmldocs:doc1">
   <xmlprop:style>
     <rdf:Description>
       <rdf:value rdf:resource="urn:x-css:stylesheet1"/>
       <dc:title>_Alice in Wonderland_ on a Small Device</dc:title>
     </rdf:Description>
   </dc:creator>
</rdf:Description>

There's no way you could propose a subproperty for xmlprop:style instead of
dc:title (as you could with oebps:role). Nothing besides rdf:value seems
right for the object valuu, either (would you propose the b-node object of
the xmlprop:style property to have its own xmlprop:style instead?). I'm
certainly open to alternatives---I've been searching for them for months.

There are therefore two major issues here that are problematic:

1. Whether b-nodes are appropriate for encoding contextual properties. (You
don't seem to think they are, which worries me. Please tell me an
alternative.)

2. Whether, if b-nodes are used for contextual properties, the semantics of
the rdf:value property are such that it allows the construct to be compliant
with RDF Schema range constraints for the original property. (You claim that
"RDF defines no formal semantics" for rdf:value, which worries me even more.
How then can rdf:value allow compliance with an RDF Schema, as you earlier
said it could, as rdf:value would therefore not be any different than
foo:bar, if rdf:value has no formal semantics in RDF?)

Related issue: Since Qualified Dublin Core uses b-nodes all the time for
contextual values, and since Dublin Core was the original poster child for
RDF, how does the validity of b-node/rdf:value construction fit into all
this?

Getting more worried,

Garret

Received on Tuesday, 11 June 2002 10:20:59 UTC