Re: Issue jsr-118 (global datatyping)

Patrick.Stickler@nokia.com wrote:

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


Yes.


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


No.  Dealing with literals this way in CC/PP may be a Bad Thing (e.g., 
it may create a lack of interoperable semantics with other 
applications), but I don't think it's properly described as 
non-monotonicity.  It's always going to be the case that an app that 
uses a specialized vocabulary with built-in meaning that it understands 
is going to be able to draw more conclusions about graphs using that 
vocaulary than an RDF-only application.  This is true of OWL, for 
example.  This doesn't mean OWL is introducing non-monotonicity between 
the RDF and OWL layers.  The same is true for specialized 
interpretations of schemas and literals (it's an application specific 
way of interpreting the RDF, just as a specialized vocabulary would be). 
  We can still claim it's a bad idea without describing it as 
non-monotonicity.


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


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Thursday, 3 April 2003 08:31:38 UTC