RE: Issue jsr-118 (global datatyping)

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 UTC