Redesigning CC/PP for tidy literals

This is offered as an exercise in exposition, NOT as a proposal of any kind.

It does not offer any new arguments for or against either of the datatyping 
approaches.

My intent is to explore, in as practical terms as I can, the effect of tidy 
literals on the assumptions that (I perceive) to underlie the design of 
CC/PP.  What I aim to do is take the previously offered examples of CC/PP 
and show how I would suggest to redesign it in light of literals 
effectively all being strings.

My conclusions:
- with a modest change of syntax, the tidy literals approach works 
perfectly well for achieving the goals of CC/PP (other than syntactic 
compatibility with UAProf).
- with these changes to the CC/PP profile syntax, the CC/PP schema would be 
correct as currently drafted.
- explicit datatyping does look rather clumsy;  a syntactic shorthand would 
be convenient, but not essential.
- any problems with adopting tidy literals are almost entirely down to 
maintaining backward compatibility with existing data.
- there is no loss of expressivity incurred by using tidy literals, though 
additional bNodes might be required in some cases (though not many, I 
think, given availability of typed literals).  I am fairly confident that 
advanced implementations could design around the practical effects of any 
triple bloat if that was found to be a problem (as was previously suggested 
for reification).

...

Profile example in current syntax:
[[
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
          xmlns:ccpp="http://www.w3.org/2002/05/20-ccpp#"
          xmlns:prf="http://example.com/Schema#">
   <rdf:Description rdf:about="http://example.com/MyProfile">
     <ccpp:component>
       <rdf:Description rdf:about="http://example.com/TerminalHardware">
         <rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform" />
         <prf:cpu>PPC</prf:cpu>
         <prf:cpuModel>604</prf:cpuModel>
         <prf:displayWidth>604</prf:displayWidth>
         <prf:displayHeight>200</prf:displayHeight>
       </rdf:Description>
     </ccpp:component>
   </rdf:Description>
</rdf:RDF>
]]

Revised for tidy literals:
[[
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
          xmlns:ccpp="http://www.w3.org/2002/05/20-ccpp#"
          xmlns:prf="http://example.com/Schema#">
   <rdf:Description rdf:about="http://example.com/MyProfile">
     <ccpp:component>
       <rdf:Description rdf:about="http://example.com/TerminalHardware">
         <rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform" />
         <prf:cpu>PPC</prf:cpu>
         <prf:cpuModel>604</prf:cpuModel>
         <prf:displayWidth 
rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#integer">604</prf:displayWidth>
         <prf:displayHeight 
rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#integer">200</prf:displayHeight>
       </rdf:Description>
     </ccpp:component>
   </rdf:Description>
</rdf:RDF>
]]

So far, the only change is that the untyped literal is replaced by a typed 
literal.

Simple label values (prf:cpu, prf:cpuModel) are not affected.

...

Next, I look to my proposed example for incorporating less/greater than 
constraints in a profile, which is part of the basis for how the CONNEG 
feature matching matches profiles:

Adding value comparison constraints in the "CC/PP style" -- this isn't 
CC/PP because no such things are defined, but it's indicative of how I 
would see it evolving to provide a generic metching framework:
[[
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
          xmlns:ccpp="http://www.w3.org/2002/05/20-ccpp#"
          xmlns:val="http://example.com/Values#"
          xmlns:prf="http://example.com/Schema#">
   <rdf:Description rdf:about="http://example.com/MyProfile">
     <ccpp:component>
       <rdf:Description rdf:about="http://example.com/TerminalHardware">
         <rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform" />
         <prf:cpu>PPC</prf:cpu>
         <prf:cpuModel>604</prf:cpuModel>
         <prf:displayWidth>
           <val:Integer>
              <val:le>604</val:le>
           </val:Integer>
         </prf:displayWidth>
         <prf:displayHeight>
           <val:Integer>
              <val:le>200</val:le>
           </val:Integer>
         </prf:displayHeight>
       </rdf:Description>
     </ccpp:component>
   </rdf:Description>
</rdf:RDF>
]]

Revised for tidy literals:
[[
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
          xmlns:ccpp="http://www.w3.org/2002/05/20-ccpp#"
          xmlns:val="http://example.com/Values#"
          xmlns:prf="http://example.com/Schema#">
   <rdf:Description rdf:about="http://example.com/MyProfile">
     <ccpp:component>
       <rdf:Description rdf:about="http://example.com/TerminalHardware">
         <rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform" />
         <prf:cpu>PPC</prf:cpu>
         <prf:cpuModel>604</prf:cpuModel>
         <prf:displayWidth>
           <val:Integer>
              <val:le 
rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#integer">604</val:le>
           </val:Integer>
         </prf:displayWidth>
         <prf:displayHeight>
           <val:Integer>
              <val:le 
rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#integer">200</val:le>
           </val:Integer>
         </prf:displayHeight>
       </rdf:Description>
     </ccpp:component>
   </rdf:Description>
</rdf:RDF>
]]
Again, the change is to replace the untyped literals with typed literals.

Notes:
(a) val:Integer is an RDF class name corresponding to the value space of 
the XML schema integer datatype.
(b) the introduction of value constraints effectively works by introducing 
a bNode denoting the value and describing it with properties.  A similar 
approach could be used for denoting exact values and datatype properties; e.g.

         <prf:displayHeight>
           <val:Integer>
              <xsd:integer>200</xsd:integer>
           </val:Integer>
         </prf:displayHeight>

...

#g


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

Received on Friday, 27 September 2002 13:20:26 UTC