W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2003

RE: Issue jsr-118 (global datatyping)

From: <Patrick.Stickler@nokia.com>
Date: Thu, 3 Apr 2003 11:23:17 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBB64@trebe006.europe.nokia.com>
To: <gk@ninebynine.org>, <w3c-rdfcore-wg@w3.org>


Er... you're telling them to use plain literals in the RDF but
interpret them as typed literals by the applications. This
means that conclusions drawn from an RDF-only application about
those CC/PP statements will differ from conclusions drawn by
a CC/PP application.

That means that non-monotonicity is being introduced between the
RDF and CC/PP layers.

No?

Patrick


> -----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
> 
> 
Received on Thursday, 3 April 2003 03:23:19 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:56:50 EDT