Dan's proposal for "datatyping"

OK, so I objected in the meeting... but I have reflected some more.

First, speaking for myself without consideration for CC/PP, I'd be happy to 
go along with Dan's idea.  My continuing position in favour of untidy 
literals, not so strongly held, has been in defense of the design 
assumptions that went into CC/PP.  So the remainder of this is predicated 
on consensus swinging in favour of tidy literals.

Dan's point, if I represent it correctly, is that we don't need typed 
literals because if we assume datatype properties relating values to 
lexical forms, we can use them as "interpretation properties".

That is, the intent of the expression:

   jenny age xsd:integer"10" .

can be equivalently expressed as:

   jenny age _:x .
   _:x xsd:integer "10" .

The values of IEXT(I(age)) that make the first form true are exactly those 
that make the second true.

The only substantive objection to this that I can think of is the concern 
for triple-bloat; e.g. integer valued-properties now need two triples 
instead of one.  (I can imagine that optimization would be possible, but 
that would be a lot of work.)  I'd expect, e.g.,  Mike Dean to oppose this.

...

[1] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Sep/0353.html

So if I now refer to my thoughts about redesigning CC/PP for use with tidy 
literals [1], where I wrote:

[[
          <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>
]]

I would instead write something like:
[[
          <prf:displayWidth>
             <rdf:Description>
                <xsd:integer>604</xsd:integer>
             </rdf:Description>
          </prf:displayWidth>
          <prf:displayHeight>
             <rdf:Description>
                <xsd:integer>200</xsd:integer>
             </rdf:Description>
          </prf:displayHeight>
]]

or just:
[[
          <prf:displayWidth xsd:integer="604" />
          <prf:displayHeight xsd:integer="200" />
]]

Syntactically, the first form is quite a big wrench for CC/PP and the 
second is no worse, indeed more attractive, than my previous redesign [1], 
but (on the assumption of literals always denoting string values) would 
only affect properties with non-string values.  Properties with string 
values would not be affected, and I *think* that's reasonably true of many 
of the UAProf attributes.

Technically, as I indicated in [1], I think this kind of approach is the 
best way forward for CC/PP in RDF, and would, I believe, lay the 
appropriate groundwork for a full content negotiation framework based on 
CC/PP, using CONNEG-like ideas for capability matching [2], probably based 
on OWL vocabulary.

Practically, it's a bit of a step away from the design assumptions that 
underpin UAProf thinking.  I think moving to such a generic negotiation 
framework would not work well with UAProf properties as currently 
defined.  As far as I can tell that community have never truly bought in to 
the idea of using RDF for this purpose -- which (off-the-record) does make 
me wonder whether CC/PP concerns here are really that important.

#g
--

[1] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Sep/0353.html

[2] http://www.ietf.org/rfc/rfc2533


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

Received on Tuesday, 26 November 2002 14:12:23 UTC