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

I have some added commentary on this issue (and I'm feeling rather
vindicated in having raised the point about the WG needing to say more
about rdf:value than simply that it is a property and has no formal
semantics!)

Garret Wilson wrote:
> 
snip
> 
> 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.)

I suspect that what Brian is uncomfortable about isn't, strictly
speaking, the use of b-nodes for encoding contextual properties, since
these are just one type of non-binary relation, and the M&S consistently
used b-nodes with rdf:value to encode these.  Your stylesheet example
seems to be another one of these, and seems relatively unproblematic. 
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 (and if it were, it wouldn't work for some of the
other uses people use rdf:value for;  I'll have more to say on this
below).  RDF b-nodes are equivalent to the existentially quantified
variables used in logic, but RDF doesn't have an equality relation
defined.  And, unless I'm mistaken, the M&S didn't have an example of
this particular usage.  

> 
> 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?)

A couple of points about this.  First, when Brian said 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 think he had the
right idea, but went a bit too far.  Your concern about compliance with
the schema assumes that the schema is declaring a set of strict validity
constraints on instances, which this instance would violate.  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.  You
could certainly define a schema processor whose goal was validitly
checking according to some strict interpretation, and which would barf
on this instance.  You could also imagine a schema processor which
would, as Brian suggested, use the given information to conclude that,
even though you hadn't explicitly said so, the b-node must be of type
Person, because the value of the dc:creator property must be of type
Person.  Remember that RDF Schema doesn't define a strict OO type
system.  

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? 

Third, just because rdf:value has no *formal* semantics in RDF doesn't
mean it doesn't have *informal* semantics.  The informal semantics of
rdf:value are that it gives the "principal" or "main" value of what is
essentially a structured property value, just as this was described in
the M&S (sections 2.3 and 7.3).  However, this is just a convention (as
I understand it).  Offhand, it's hard to think of a way to convey the
general idea formally, because its interpretation varies from case to
case.  Consider the "units" example from M&S section 7.3:  it has (in
triples) 

foo:John_Smith n:weight _:johnsweight (a b-node)
_:johnsweight rdf:value 200
_:johnsweight n:units n:Pounds

This is a fairly conventional way to model values with units, but still,
the actual *value* isn't 200, it's 200 pounds, i.e., the number 200
multiplied by a standard unit of weight;  both components are equally
significant in determining the real value [OK datatype fans, I know that
in RDF 200 is actually a string, but bear with me for a minute
willya?].  It seems to me it would be just as legitimate (although
perhaps unconventional), to model this as

foo:John_Smith n:weight _:johnsweight (a b-node)
_:johnsweight rdf:value n:Pounds
_:johnsweight n:multiplier 200

Note that, unless I'm mistaken, there isn't anything currently that
requires the value of an rdf:value property to be a literal
(non-resource), which allows for the model used in the Jane Doe
example.  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.  RDF Core might
well want to be explicit about whether the value of an rdf:value
property can be a resource or not.  

> 
> 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

I don't see any need to worry, since I don't think the new specs
actually change anything in this regard.  After all, how formal were the
original semantics for rdf:value?  And on what basis given in the
original M&S would the Jane Doe example have passed or not passed schema
checking?

--Frank

-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752

Received on Tuesday, 11 June 2002 13:04:06 UTC