RE: Proposal to drop S from consideration

Patrick,

I don't find your focus on the idea of "pairing" lexical form and datatype 
to be particularly helpful.

In particular, I think there are RDF (mediating) applications where the 
pairing may be completely irrelevant.  Consider the example of 
<dc:date>2001-11-29</dc:date>.

For "endpoint" applications that fully understand the schema being used, 
and its intended interpretation, the element value may be interpreted as a 
date, and subjected to date-wise comparisons, calculations, presentation, etc.

But consider the role of an intermediary RDF information store, for which 
it may be sufficient to satisfy a query that that the dc:date property 
value string matches some supplied string in a query.  There's no need to 
pair the literal with a data type here -- the required processing can be 
performed without knowledge of the data type.

You also claim, of P/DAML/U/P++:
>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.

But what is "the property" here?  I think part of the thinking behind S is 
that there may be several properties that relate the subject to different 
representations of some intended value, with literal strings being at the 
end of the food chain.

(The following makes reference to Sergey's example diagram...)

A simplistic property definition can reference the literal string directly, 
and the representation convention would be implicit in the property 
(whether or not associated with a defined data type).  Semantically, the 
relational extension of the property simply contains pairs like:

    IEXT(weight_in_Kg_as_string) >= { <Jenny,"12">, <Robby,"14"> }

(where 'Jenny' above denotes the child, and '"12"' denotes the two 
character string, etc., and '>=' denotes set containment.)

A more savvy form of definition could use one or more intermediate 
resources to more precisely capture the statement in relation to other 
knowledge about numerics and units:

    IEXT(weight)    >= { <Jenny,twelve_kilograms>, <Robby,fourteen_kilograms> }
    IEXT(inKg)      >= { <twelve_kilograms,twelve>, 
<fourteen_kilograms,fourteen> }
    IEXT(inDecimal) >= { <twelve,"12">, <fourteen,"14"> }

(where 'twelve_kilograms' above denotes the mass, 'twelve' denotes the 
integer, etc.)

I don't think there's any fundamental difference between S and the other 
schemes with respect to treatment of properties, which is what you seem to 
imply.

#g
--


At 02:49 PM 11/29/01 +0200, Patrick.Stickler@nokia.com wrote:
> > (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

------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
       __
      /\ \
     /  \ \
    / /\ \ \
   / / /\ \ \
  / / /__\_\ \
/ / /________\
\/___________/

Received on Thursday, 29 November 2001 14:07:27 UTC