RE: Issue jsr-118 (global datatyping)

> -----Original Message-----
> From: ext Frank Manola [mailto:fmanola@mitre.org]
> Sent: 03 April, 2003 16:52
> To: Stickler Patrick (NMP/Tampere)
> Cc: gk@ninebynine.org; w3c-rdfcore-wg@w3.org
> Subject: 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.
> 

It's one thing to have vocabulary that will not be understood at
lower levels, or for which there will be inferences that can be
made at a higher level that do not hold at the lower levels.

It's another issue to have different inferences at different
levels based on the very same statements.

If my RDF-only application holds the following entailment:

IF
   _:x ccpp:BitsPerPixel "2" .
   _:x ccpp:Model "2" .
THEN
   _:x ccpp:BitsPerPixel _:v .
   _:x ccpp:Model _:v .

yet if for my CC/PP application, that entailment does *not* hold, 
then that is non-monotonicity, and that is completely unnacceptable.

Compare to

   _:x ccpp:BitsPerPixel "2"^^ccpp:Number .
   _:x ccpp:Model "2"^^ccpp:Literal .

which does not entail

   _:x ccpp:BitsPerPixel _:v .
   _:x ccpp:Model _:v .

And note that I have not used any vocabulary but the CC/PP vocabulary.

The proposal promotes non-monotonicity.

We should recommend to CC/PP that they adopt typed literals in their 
serializations since the CC/PP semantics clearly deals with datatype
values.

CC/PP knowledge about terminals is only one subset of knowledge about
terminals, and that knowledge should have a consistent interpretation
both by CC/PP specific applications as well as arbitrary RDF applications
consuming that knowledge.

As such, any non-monotonicity, or any other incompatibility between
CC/PP specific and RDF-general interpretations of CC/PP expressed
knowledge should be avoided.

Patrick


> > 
> > 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 Friday, 4 April 2003 01:36:31 UTC