- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Thu, 21 Feb 2002 20:01:21 -0000
- To: <w3c-rdfcore-wg@w3.org>
Pat: > 1. [Patrick?] and Graham want range-sensitive inline literals. > 2. Dan C. wants an inline literal used with no datatyping to > unambiguously denote a character string. > 3. We all want the logic to be monotonic. > Something has to give. I want range-sensitive inline literals. For me that was a major motivation for TDL, and an attraction of P. It is also IMO the only *requirement* as opposed to *disederata*. As I see it, we have four different worked out proposals for inline literals: S-B P (with Bermuda triangle model theory) TDL global Syntactic transform to rdf:value The first three are all talking about the same idiom <Jenny> --ex:age--> "15" ex:age --some:range--> eg:Integer . and the differences lie in the subtly of the model theoretic treatment. S-B provides no model theoretic treatment other than tidiness. P+Bermuda and TDL both provided some model theory at the expense of tidiness. P+Bermuda is superior to TDL. The syntactic transform, where the two triples above somehow get transformed into three triples: <Jenny> --ex:age--> _:bnode --> "15" . ex:age --some:range--> eg:Integer . has the advantage of maintaining tidiness and delivering an integer. Also any non-monotonicity can be buried within whether we use the transform or not. A further advantage is that by making inline literal idiom datatyping part of the graph the treatment of datatyped values is explicit in the data model (which many users understand) as opposed to hidden away in the model theory (which is generally difficult). Perhaps we should drop all other disiderata. i.e. just do this, and do it in such a way as we remain agnostic about which model theoretic treatment (S-B or P+Bermuda) we use. The only practical differences are whether certain corner case descriptions are ill-formed or not. (eg. prop --range--> integer, prop--range--> string, r--prop-->"10") We can punt on the model theory for datatyping, and provide a syntax for the one bit we can agree on. Jeremy
Received on Thursday, 21 February 2002 15:01:47 UTC