RE: datatypes: conversation with Mark Butler, chair of cc/pp

I agree with most of Mark's introductory assessment.

The issue was discussed in early CC/PP debates, and I was unable to 
persuade the group that implicit typing was unhelpful, mainly for the 
reasons of UAProf compatibility that Mark alludes to.

The CC/PP attribute type and schema elements (which are similar to what 
Mark has suggested here) was intended to provide the groundwork for 
migration to more explicit typing, via RDF schema, and has been a 
significant influence on my preferences for RDF datatyping.

Regarding Mark's question in the final paragraph, it seems likely to me 
that the OWL work to incorporate description logic capabilities will go 
some way to achieving this.  A common idea between DLs and the IETF CONNEG 
work is performing a subsumption calculation to find an intersection 
between described value sets (though many details of the calculation differ).

#g
--

At 11:48 AM 8/16/02 +0100, Butler, Mark wrote:

>Hi Patrick
>
>Firstly thanks for your detailed reply.
>
> > The datatype that constrains the value of BitsPerPixel to
> > the set of integers is implicit in the CC/PP standard. It
> > couldn't be explicit yet, because RDF doesn't provide a
> > mechanism for making it explicit.
>
>The people who originally worked on UAProf and CC/PP seem to think of it as
>being implicit, but my view is slightly different: I think CC/PP and UAProf
>desperately need a way to make it explicit, because I think CC/PP processors
>should be general purpose and able to process any vocabulary as this is
>essential for device independence. This means that vocabulary data typing
>information shouldn't be hardcoded into processors, because processors (even
>if they are only processing UAProf) have to process several vocabularies.
>For example UAProf currently puts the data type in the comments field in the
>schema e.g.
>
><rdf:Description ID="BitsPerPixel">
>   <rdf:type rdf:resource="http://www.w3.org/TR/PR-rdf-schema#Property" />
>   <rdfs:domain rdf:resource="#HardwarePlatform" />
>   <rdfs:comment>
>Description: The number of bits of color or grayscale
>information per pixel, related to the number of colors or shades of
>gray the device can display.
>Type: Number
>Resolution: Override
>Examples: "2", "8"</rdfs:comment>
>   </rdf:Description>
>
>So at the moment my processor has to parse the comments field to get the
>data type information! Clearly this is not ideal. I've proposed an
>alternative form to OMA (see below)
>
><rdf:Description rdf:about="&ns-prf;BitsPerPixel">
>   <rdf:type rdf:resource="&ns-rdfs;Property"/>
>   <rdfs:domain rdf:resource="&ns-prf;HardwarePlatform"/>
>   <rdfs:range rdf:resource='&ns-prf;Number'/>
>   <prf:resolutionRule rdf:resource='&ns-prf;Override'/>
>   <rdfs:comment xml:lang="en">
>Description:  The number of bits of color or grayscale information per
>pixel, related to the number of colors or shades of gray
>the device can display.
>Type:         Number
>Resolution:   Override
>Examples:     "2", "8"
>   </rdfs:comment>
></rdf:Description>
>
>which is much easier for an RDF processor to read. Now obviously when data
>types are finalized, the schema should use the approved data typing method.
>The only problem then would be persuading OMA to make this change. Perhaps
>as you work for Nokia you could help persuade OMA that revising the UAProf
>schemas in this way would be helpful?
>
> >From your other comments, it sounds like we are in agreement.
>
> > IMO, we will want our systems to become more modular and
> > generic insofar as knowledge representation and inference
> > is concerned, and to have to rely less on application specific
> > interpretation, so having the above sort of fuzzyness in
> > the datatyping semantics and pushing the ultimate interpretation
> > out to the application layer will negatively impact scalability
> > and portability of knowledge, as one will have to be concerned
> > whether all applications utilizing the same RDF expressed
> > knowledge employ the same actual interpretations.
>
>Yes, exactly. The only problem is this is hard: we don't have this in CC/PP
>yet, because processing CC/PP i.e. performing resolution to merge multiple
>profiles isn't fully defined so is potentially application dependent. It is
>fully defined in UAProf, but other CC/PP vocabularies don't have to follow
>the UAProf model. So my big concern with CC/PP at the moment is that when
>people create new vocabularies they may use it in a very application
>specific way, which negates the advantage of using CC/PP. If CC/PP has this
>problem, my guess is it's potentially even harder for RDF.
>
>Incidentally I characterise the resolution problem as follows: you have
>multiple values for the same attribute of the same resource but with
>different contexts so it is necessary to determine the most appropriate
>context to get the most appropriate value. I think this is not just a
>problem for CC/PP but also a general task for RDF. Is it likely future work
>will consider standardized approaches to this problem?
>
>best regards
>
>Mark H. Butler, PhD
>W3C CC/PP Working Group Chair
>Research Scientist                HP Labs Bristol
>mark-h_butler@hp.com
>Internet: http://www-uk.hpl.hp.com/people/marbut/

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Friday, 23 August 2002 09:57:48 UTC