- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Thu, 29 Nov 2001 11:04:26 +0000
- To: Jan Grant <Jan.Grant@bristol.ac.uk>
- Cc: Dan Connolly <connolly@w3.org>, RDFCore Working Group <w3c-rdfcore-wg@w3.org>
At 09:50 AM 11/29/01 +0000, Jan Grant wrote: > > Applications on top of RDF parsers that know about dc:date > > take the string and do date stuff with it. But not > > the RDF parser itself. > >You seem to have jumped tracks somewhere in this argument. RDF Software ><> RDF Parser. I think this may be a key point of disconnect in the debate. From my perspective of arguing for compatibility with CC/PP, I can see this going two ways: (a) literals always denote string values according to RDF model theory, and it's up to an application to interpret the string. This is, roughly, where S leads us. If RDF literals cannot denote integers, what can we make of statements like this?: ex:foo ccpp-client:pix-x "1024" . ccpp-client:pix-x rdfs:range xsd:integer . If we can use the data type names to indicate a lexical restriction on the form of string (per XML schema datatypes lexical space) then I think this can work. I think that all of the truths that can be expressed with integer denotations of literals, etc., can still be expressed (by way of different interpretations than would be used if literals denote integers, etc), though I'd also imagine that some unintended interpretations would also yield truth for some expressions. From a framework like this, I think that Dan's preferred idiom, using S, could be build through the addition of vocabulary to reference resources that denote arbitrary values (integers, etc) and properties that contain these values in their relational extensions. C.f. my comments at http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0616.html http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0574.html (Maybe the latter should be viewed as yet another proposal?) (b) RDF model theory allows literal to denote arbitrary data values. Then we seem to need the P/P++ style of instance-specific data typing to capture the intent of statements containing literals. This does have the disadvantage of being more theoretically complex, but it does seem to capture and formalize intuitions about the use of RDF. I think these two cases represent situations thus: (a) RDF core software (i.e. parser + common semantics) deals with only literals-denoting-strings. It's up to RDF applications to interpret these values as specific data types. (b) RDF core software deals with literals denoting arbitrary values. As I write this, I'm thinking that the difference between these cases is really very small, even trivial. But I'm struggling to find the words to express what I'm perceiving here. Roughly, I think that the P++ approach is providing more information hence further constraining models of some given RDF. The idioms based on S have a similar effect. But if literals-as-strings are used directly without the additional idioms suggested by Dan and Sergey then more is left to the application to decide what is and is not a meaningful statement in the context of some given schema. > > I see S as a straightforward layer atop RDF 1.0. I can (mostly) see that too... the debate then becomes one about the interpretation of XSD datatype URIs. Again, see: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0574.html >For what it's worth, I'm coming round to the "would really rather not >live with S"* point of view. > >I'd rather see P++/U' than P/U (where U' doesn't actually do gnarly >things with URIs, but still has the low-level typed data of U). I'm wavering... for me it hinges on the handling of XSD datatype URIs. (BTW, I said in a recent message to Pat that I agreed that the XSD URIs should denote the data type's value space... I'd like to suspend that opinion for the time being.) #g ------------------------------------------------------------ Graham Klyne MIMEsweeper Group Strategic Research <http://www.mimesweeper.com> <Graham.Klyne@MIMEsweeper.com> __ /\ \ / \ \ / /\ \ \ / / /\ \ \ / / /__\_\ \ / / /________\ \/___________/
Received on Thursday, 29 November 2001 07:08:36 UTC