RE: Issue jsr-118 (global datatyping)

> -----Original Message-----
> From: ext Graham Klyne [mailto:GK@ninebynine.org]
> Sent: 03 April, 2003 21:19
> To: Stickler Patrick (NMP/Tampere); w3c-rdfcore-wg@w3.org
> Subject: RE: Issue jsr-118 (global datatyping)
> 
> 
> At 11:23 03/04/2003 +0300, Patrick.Stickler@nokia.com wrote:
> 
> 
> >Er... you're telling them to use plain literals in the RDF but
> >interpret them as typed literals by the applications.
> 
> No I'm not.  Plain literals remain plain literals.
> 
> I'm suggesting that the meaning of (say, numeric) CC/PP attribute 
> properties be defined along the lines of:
> 
>      ex:someDevice ex:displayWidth "200" .
> 
> be interpreted as saying that the property 'ex:LdisplayWidth' relates 
> devices to character sequences which are decimal text 
> representations of 
> their display width.  This is perfectly legitimate RDF as 
> currently specified.

It's legitimate RDF, but it is non-monotonic, since CC/PP applications
will be interpreting those property values as integers, not strings.

See my reply to Frank...


Patrick



> #g
> --
> 
> > > -----Original Message-----
> > > From: ext Graham Klyne [mailto:gk@ninebynine.org]
> > > Sent: 03 April, 2003 11:03
> > > To: Stickler Patrick (NMP/Tampere); w3c-rdfcore-wg@w3.org
> > > Subject: RE: Issue jsr-118 (global datatyping)
> > >
> > >
> > > At 10:36 03/04/2003 +0300, Patrick.Stickler@nokia.com wrote:
> > >
> > > >Please, let's not recommend that CC/PP introduce
> > > non-monoticity between
> > > >the RDF and Application layers!
> > >
> > > Indeed.  My proposal is no such thing.
> > >
> > > #g
> > > --
> > >
> > > > > -----Original Message-----
> > > > > From: ext Graham Klyne [mailto:gk@ninebynine.org]
> > > > > Sent: 02 April, 2003 18:26
> > > > > To: w3c-rdfcore-wg@w3.org
> > > > > Subject: Issue jsr-118 (global datatyping)
> > > > >
> > > > >
> > > > >
> > > > > Er, how did this issue end up being assigned to concepts?
> > > > >
> > > > > Anyway, here's a proposed resolution for discussion:
> > > > >
> > > > > Rejected, or maybe postponed.
> > > > >
> > > > > [[
> > > > > We have much sympathy with this request.  But the working
> > > > > group spent much
> > > > > time exploring options to allow global datatyping of the kind
> > > > > requested
> > > > > here, and were unable to find a solution that allowed
> > > this and also
> > > > > preserved other strongly-desired features of RDF.  It might
> > > > > be possible to
> > > > > devise an alternative syntax-based approach to global
> > > > > datatyping, but I
> > > > > think even that would not fully capture the goals of CC/PP
> > > > > here, to express
> > > > > capability profile feature types in a schema separately from
> > > > > on-the-wire
> > > > > profiles.
> > > > >
> > > > > The current version of CC/PP formally treats all attributes
> > > > > as textual
> > > > > values (i.e. plain literals in RDFcore parlance).  The global
> > > > > datatyping
> > > > > could be achieved for CC/PP applications by continuing to
> > > > > formally treat
> > > > > all CC/PP attributes as textual values and:
> > > > > (a) using range constraints to limit the allowed lexical
> > > values, and
> > > > > (b) building the lexical-to-value mapping into the semantics
> > > > > of the CC/PP
> > > > > attribute properties.
> > > > >
> > > > > (a) would require some URIs to be designated to denote
> > > > > classes for the
> > > > > lexical space of the datatypes used.  Currently, CC/PP uses
> > > > > its own URIs
> > > > > for datatypes, so this would be easily accommodated.  In
> > > > > practical terms, I
> > > > > see no changes to current CC/PP applications required by this
> > > > > change:  what
> > > > > is described above is a formal device to make CC/PP as
> > > > > currently defined be
> > > > > consistent with the current semantic framework.
> > > > >
> > > > > The downside of this approach is that it is a non-standard
> > > > > approach to
> > > > > using literals to indicate datatype values, and it may add
> > > > > some complexity
> > > > > if and when future developments of CC/PP require to express
> > > > > comparisons
> > > > > between CC/PP attribute values and datatype values from other
> > > > > RDF descriptions.
> > > > > ]]
> > > > >
> > > > > Note to WG:  the suggested CC/PP approach is basically a
> > > strategy for
> > > > > implementing CC/PP under the old datatyping proposal 'S',
> > > > > ignoring the new
> > > > > datatyping facilities.
> > > > >
> > > > > #g
> > > > >
> > > > >
> > > > > -------------------
> > > > > Graham Klyne
> > > > > <GK@NineByNine.org>
> > > > > PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
> > > > >
> > > > >
> > >
> > > -------------------
> > > Graham Klyne
> > > <GK@NineByNine.org>
> > > PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
> > >
> > >
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
> 
>

Received on Friday, 4 April 2003 01:44:00 UTC