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

RE: Issue jsr-118 (global datatyping)

From: <Patrick.Stickler@nokia.com>
Date: Fri, 4 Apr 2003 09:45:04 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B01B90C60@trebe006.europe.nokia.com>
To: <GK@NineByNine.org>, <bwm@hplb.hpl.hp.com>, <w3c-rdfcore-wg@w3.org>

I'm also happy with a response that does not recommend any particular
approach to a solution (particularly one that is non-monotonic).


> -----Original Message-----
> From: ext Graham Klyne [mailto:GK@NineByNine.org]
> Sent: 03 April, 2003 21:21
> To: Brian McBride; w3c-rdfcore-wg@w3.org
> Subject: Re: Issue jsr-118 (global datatyping)
> This is fine with me.
> (I shall cease further discussion of my earlier proposal.)
> #g
> --
> At 10:49 03/04/2003 +0100, Brian McBride wrote:
> >At 16:25 02/04/2003 +0100, Graham Klyne wrote:
> >
> >>Er, how did this issue end up being assigned to concepts?
> >>
> >>Anyway, here's a proposed resolution for discussion:
> >
> >Whilest it starts well, I'm uncomfortable with this 
> proposal.  It feels 
> >like we are telling cc/pp folks how to do their job, which 
> is not our 
> >place to do.
> >
> >The facts here are:
> >
> >   o we have conflicting requirements which we were unable to find a 
> > compromise on
> >
> >   o we have not had strong pushback from the community on 
> the choice we 
> > have made.
> >
> >   o Mark (I beleive speaking as jsr-188) has indicated that 
> a *syntactic* 
> > solution would be acceptable to him - so he is saying they 
> don't need 
> > full long range datatyping
> >
> >I suggest a response along the lines of:
> >
> >   o the WG has considerable sympathy with this request
> >   o we tried real hard, but couldn't reconcile this with 
> other requirements
> >   o given this was a very difficult issue, we are aware 
> that we can't 
> > satisfy everybody
> >   o given the lack of strong negative feedback at last call, the WG 
> > believe that the community would rather we proceed with the 
> proposed 
> > solution, than go back and try again, with the consequent delays.
> >   o we note marks comment that a syntactic solution would 
> be acceptable 
> > and encourage cc/pp to investigate such solutions, which might have 
> > general applicability.
> >
> >     
>>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.
>>Graham Klyne
>>PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Graham Klyne
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
Received on Friday, 4 April 2003 01:45:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:54:05 UTC