W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2002

Re: handling rdf:value

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Mon, 9 Dec 2002 11:04:42 +0200
Message-ID: <00fb01c29f62$03013f60$db9316ac@NOE.Nokia.com>
To: <w3c-rdfcore-wg@w3.org>, "ext pat hayes" <phayes@ai.uwf.edu>

I like this approach very much, and it fits in nicely with
the use of rdf:value as a mechanism for scoping, as used
by alot of folks (including myself and the Adobe XMP folks)

C.f.
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0212&L=dc-architecture&T=0&F=&S=&P=726

It captures the DC concept of "dumbing down" very well, and in
a formal manner, and provides all RDF processors with a consistent 
interpretation of rdf:value in terms of such simplification.

I support Pat in inserting the proposed semantics for rdf:value
into the MT and for Frank to massage the verbage in the Primer
accordingly.

It does not appear to break any current usage of rdf:value but
rather captures the intersection of meaning shared by all of
the current uses of rdf:value in various applications.

Patrick

[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]


----- Original Message ----- 
From: "ext pat hayes" <phayes@ai.uwf.edu>
To: <w3c-rdfcore-wg@w3.org>
Sent: 09 December, 2002 06:59
Subject: handling rdf:value


> 
> 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/~phayes
> s.pam@ai.uwf.edu   for spam
> 
Received on Monday, 9 December 2002 04:04:45 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:54:49 EDT