- From: Graham Klyne <GK@NineByNine.org>
- Date: Fri, 27 Sep 2002 18:43:56 +0100
- To: RDF core WG <w3c-rdfcore-wg@w3.org>
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