Re: Proposal to drop S from consideration

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