W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > August 2002

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

From: Butler, Mark <Mark_Butler@hplb.hpl.hp.com>
Date: Fri, 16 Aug 2002 11:48:05 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04501AB9@0-mail-1.hpl.hp.com>
To: "'Patrick.Stickler@nokia.com'" <Patrick.Stickler@nokia.com>, "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>, "McBride, Brian" <bwm@hplb.hpl.hp.com>, w3c-rdfcore-wg@w3.org
Cc: franklin.reynolds@nokia.com

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/
Received on Friday, 16 August 2002 06:48:25 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:50:26 EDT