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.

#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 Thursday, 3 April 2003 13:40:26 UTC