RE: Comments on datatyping draft

I've been away, and am still catching up.  I've yet to review the new 
datatype draft, which I intend to do.  Meanwhile, I wanted to respond to 
one point.

Maybe I misunderstand the WG's intent, but I thought that we were targeting 
a purely syntactic form of datatyping that allows values other than 
strings, such as numbers, dates, etc., to appear as literal node labels in 
the abstract RDF graph.  SO if we write something like:

    <rdf:Description about="http://example.org/Person#Jenny">
       <ex:age rdf:literalType="xsd:integer">10</ex:age>
    </rdf:Description>

(for whatever string may replace "rdf:literalType") then the resulting 
abstract RDF graph contains the number 10 rather than the numeral "10".

Now, if I'm wrong about this, it would be good to know.

At 11:35 AM 8/31/02 +0300, Patrick.Stickler@nokia.com wrote:
> >
> > 3.1 Local Datatyping
> > --------------------
> >
> > I agree that the use of rdf:type here is unfortunate, and likely to
> > confuse.
>
>In what way? I *really* must be off in la la land on this one,
>as the use of rdf:type seems to me to be the most correct,
>concise, and accurate means to state that the, ahem, rdf:type
>of the typed literal node is the datatype class specified.
>
>Before I go any further, I will specify whatever term the WG
>decides to use, but with my editor's hat off, I offer the following
>comments.
>
>I think there has been an agreed principle that vocabulary will
>only be added when absolutely necessary. And I've yet to see any
>convincing argument why use of rdf:type is not completely correct.

The datatype attribute, as outlined above, is not "vocabulary" in the usual 
RDF sense.  The URI does not appear in the graph -- it's just part of the 
syntax that types the literal.  OTOH, rdf:type *is* an RDF vocabulary term 
that appears in the graph.

>The use of any other term will require additional explanation
>that, actually, it really means the *same* as rdf:type, but
>for some reasons (which I've yet to grasp) we've just used some
>other term.

But the datatype attribute (as outlined above) absolutely does not mean the 
same as rdf:type.  It's a purely syntactic device (like rdf:parseType) 
which, unlike rdf:type, is never seen in the formal semantics.

I think this pinpoints our divergence in viewpoint -- the rest of your 
comments (copied below) assume the datatyping attribute appears as an RDF 
property, which is not what I was expecting.

#g
--

>Consider the following examples, which simply define "some"
>typed resource:
>
>    <bar rdf:type="http://booga.com/wiggyhoo"/>
>    <bar foo:blarg="http://booga.com/wiggyhoo"/>
>
>which give us
>
>    ?s bar _:x .
>    _:x rdf:type <http://booga.com/wiggyhoo> .
>
>    ?s bar _:y .
>    _:y foo:blarg "http://booga.com/wiggyhoo" .
>
>respectively.
>
>Now, clearly, rdf:type must be used here if we are
>to get a URIref node for the attribute value, otherwise,
>we get a literal containing the URI. If we introduce
>another attribute other than rdf:type, we have to both
>state that it has identitical semantics to rdf:type
>as well as treat the attribute value exceptionally as
>a URIref rather than a literal just like rdf:type. But
>why? They would have identical meaning and purpose!
>
>I hope it's obvious that using rdf:type here is clearer
>and better than some new term that is otherwise identical
>in every way to rdf:type.
>
>OK, now let's consider two similar examples, with typed literals:
>
>    <bar rdf:type="http://booga.com/wiggyhoo">79*7%22.191/22</bar>
>    <bar foo:blarg="http://booga.com/wiggyhoo"79*7%22.191/22</bar>
>
>which, if literals *could* be subjects (which they can't and I'm
>not suggesting here that they should), we'd get the following
>graph:
>
>    ?s bar _:x"79*7%22.191/22" .
>    _:x rdf:type <http://booga.com/wiggyhoo> .
>
>    ?s bar _:y"79*7%22.191/22" .
>    _:y foo:blarg "http://booga.com/wiggyhoo" .
>
>Again, rdf:type does "the right thing" and provides us with the
>correct semantics.
>
>Now since we can't have literals as subjects, we use a compact
>typed literal node representation, and to get that for foo:blarg
>we would of course have to specify that foo:blarg also results in
>such a typed literal node representation, in which case, we'd get the
>same result for either term:
>
>    ?s bar <http://booga.com/wiggyhoo>"79*7%22.191/22" .
>
>But we'd still have to define that foo:blarg takes a URIref rather
>than a literal as its attribute value, otherwise, we'd get
>
>    ?s bar "http://booga.com/wiggyhoo""79*7%22.191/22" .
>
>which isn't what we want for a typed literal node.
>
>Now, we know from the semantics of typed literal nodes, that
>the typed literal node above has an rdf:type of
>http://booga.com/wiggyhoo. So which serialization most accurately
>reflects that. Clearly, I think, the one using rdf:type.
>
>And, since one can already now say
>
>    <bar rdf:type="http://booga.com/wiggyhoo"/>
>
>to express that the value of bar is "something" of type
>http://booga.com/wiggyhoo, is it not obvious that using
>a different term for the more explicit specification of
>what that something is, e.g.
>
>    <bar foo:blarg="http://booga.com/wiggyhoo"79*7%22.191/22</bar>
>
>will be far more confusing and cumbersome to explain than
>simply using the same term which already expresses
>the actual intended semantics and is recognized by parsers
>as taking a URIref attribute value rather than a literal
>string value:
>
>    <bar rdf:type="http://booga.com/wiggyhoo">79*7%22.191/22</bar>
>
>
>Eh???
>
>Am I the only one for whom this makes sense?
>
>
> > For what I understand to be the current purpose,
> > I'd tend to
> > favour using XML schema syntax in a way that is fully
> > compatible with XML
> > schema processors, leading to things like:
> >
> >    <age xsi:type="xsd:integer">25</age>
> >
> > with appropriate namespace declarations.
>
>The use of xsi:type is not possible, because rdfs:Datatype is
>not constrained to the XML Schema specification.

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

Received on Thursday, 5 September 2002 08:49:57 UTC