RE: Issue jsr-118 (global datatyping)

Please, let's not recommend that CC/PP introduce non-monoticity between
the RDF and Application layers!

Ideally, if CC/PP is going to use RDF, and wants to work with datatype
values, it should use the new datatyping facilities to do so.

We should recommend that CC/PP update their serialization to use typed
literals in their serializations in order to keep CC/PP RDF statements
semantically compatible with other RDF applications which may make use
of assertions expressed using the CC/PP vocabulary.

We use CC/PP is just part of a larger vocabulary for describing devices,
and it would be IMO far more catestrophic than lack of global datatyping
if CC/PP used plain literals for values but interpreted them as datatype
values. 

Bad... bad... bad...

Patrick


> -----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
> 
>

Received on Thursday, 3 April 2003 02:36:30 UTC