RE: Proposal to drop S from consideration

> (b) RDF model theory allows literal to denote arbitrary data 
> values.  

Though this may sound somewhat pedantic, I think it is more
accurate to say that a pairing of lexical form (literal) and
data type identity (URI) denote the data values, and the object
node of the triple represents the value denoted by that
pairing. How the pairing is attributed to that node is a 
question of idiom, not interpretation. 

With P, the value node has the literal as its label and the 
data type is paired by means of an rdfs:range constraint
defined for the predicate for which the value node serves
as the object.

With DAML, the value node has an rdf:value property with the 
lexical form (literal) as its value and an rdf:type property 
with the data type URI as its value.

With U, the value node has a URV (URI) label which encapsulates
the lexical form and provides an indirect reference to the data 
type via the knowlede defined for the URV scheme.

With P++ (which can be seen as a middle ground between P and DAML)
the value node has the literal as its label (as with P)
but also has an rdf:type property with the data type URI as its
value (as with DAML).

In all four idioms, it is the object node of the property
that represents the value, and the lexical form (literal) and data
type (URI) are associated with that value node directly in one way 
or another, and all with the same interpretation, that the value
that is represented by the object node is identified by the pairing
of lexical form and data type. 

> I think these two cases represent situations thus:
> (a) RDF core software (i.e. parser + common semantics) deals 
> with only 
> literals-denoting-strings.  

And the constructs for defining pairings of literals with
data type URIs.

> It's up to RDF applications to 
> interpret these 
> values as specific data types.

Or rather, it's up to applications to interpret the pairings
as data values, in terms of the data type. A given API may
in fact provide a generalized access to such pairings regardless
of the idiom used to define them.

> (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.

The P/DAML/U proposal does not suggest basing data typing on
literals alone, but on the pairing of literal and data type URI.

One could also view the S proposal as an idiom for defining
such pairings. The question then is simply which idiom(s) are
(a) most compatible with current usage and (b) most efficient with
regards to the minimum mechanisms needed to define those pairings.
 
> > > I see S as a straightforward layer atop RDF 1.0.
> 
> I can (mostly) see that too...  

I agree, as stated above, from the viewpoint of taking the pairing
of lexical form and data type identity as the basis for the data
typing model employed by RDF.

It all boils down to the question of how we achieve that pairing
in the most consistent, clear, and compatible fashion, IMMHO.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Thursday, 29 November 2001 07:49:56 UTC