After reading Franks section in the primer more carefully, I would
like to make the following suggestion for how to handle rdf:value,
which I think codifies the intent rather better than any other idea
we've had so far. I've rewritten Frank's section 4.2 along these
lines in the version at
http://www.coginst.uwf.edu/~phayes/RDF-Primer-modified.html, but of
course this rewrite is only OK if people agree to the treatment.
-------
Frank characterizes the typical use of rdf:value as a way to indicate
a 'primary' value of a multi-arity relation. (Note, this is not at
all the same notion as a primary field in a DB.) That is, when R is a
more-than-binary relation, but can be abbreviated usefully as a
binary one by ignoring some of its arguments, then the rdf:value is
the argument that should not be ignored. In cases like this, we can
typically think of the binary form as an abbreviation or summary of
the longer formulation, where some detail has been omitted or
suppressed.
I think that this very nicely captures the intended range of uses for
rdf:value, and doesn't get it confused with issues like
distinguishing dimensions from values or textual forms from real
values, which I had often gotten it confused with. But it suggests
the following slightly modified treatment.
The *strictly correct* use of rdf:value is to do *exactly* the above,
and no more; ie to say, when a relation with more than two arguments
is described by having a structured value which itself has the other
arguments as values, which one of those arguments can be
appropriately used as the single argument when the n-ary relation is
abbreviated or summarized as a binary relation, ie a simple property.
For example, using the address example that Frank gives:
exstaff:85740 exterms:address _:johnaddress .
_:johnaddress exterms:street "1501 Grant Avenue" .
_:johnaddress exterms:city "Bedford" .
_:johnaddress exterms:state "Massachusetts" .
_:johnaddress exterms:Zip "01730" .
an appropriate use of rdf:value here might be to add:
exstaff:85740 exterms:address _:johnaddress .
_:johnaddress exterms:street "1501 Grant Avenue" .
_:johnaddress exterms:city "Bedford" .
_:johnaddress exterms:state "Massachusetts" .
_:johnaddress exterms:Zip "01730" .
_:johnaddress rdf:value "01730" .
which would say that the way to succinctly abbreviate this in binary
form would be to just use the Zip code as the address, ie that it is
correct, even if less informative, to also write:
exstaff:85740 ex:terms:address "01730" .
Now, of course, this kind of strictly correct usage means that one
has to say the value twice; once with its correct attaching property
and once again with rdf:value; and so users may wish to abbreviate
this by omitting the 'correct' property, and leaving it implicit; but
that strategy is inherently risky, as the intended meaning of
rdf:value is now contextual and liable to be misunderstood if taken
in isolation. So, caution.
On this view, the 'proper' way to write the kilogram example would be
aaa weightIs _:x .
_:x ex:quantity "24" .
_:x rdf:value "24"
_:x ex:units ex:kilograms .
And omitting the second triple is an obvious economizing strategy,
but users are cautioned that it has its risks.
-----
If people like this idea than it could be captured formally as a RDF
semantic condition corresponding to the inference rule:
aaa ppp bbb .
bbb rdf:value ccc .
-->
aaa ppp ccc .
for any property ppp. This would fit very naturally into
rdf-entailment. But as this goes beyond
http://www.w3.org/2000/03/rdf-tracking/#rdfms-replace-value.
I hereby REQUEST feedback from the WG before inserting it into the
MT. If people think it should be there then I can put it in one
evening this week. All the proofs and so on are transparent to this
addition.
Pat
PS. BTW, this account allow you to use rdf:value for more than one of
the properties, and the semantics then would be that *either* of them
could be correctly used as the abbreviating property, eg if you also
said that the city was an rdf:value, then it would be correct to use
either the zip code or the city as the value of the simple address
property instead of the structured value encoding all the aspects of
the address.
--
---------------------------------------------------------------------
IHMC (850)434 8903 home
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32501 (850)291 0667 cell
phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayess.pam@ai.uwf.edu for spam