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:18:47 UTC