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

Re: Comments on datatyping draft

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 5 Sep 2002 16:18:22 +0300
Message-ID: <003301c254de$b551b920$294516ac@NOE.Nokia.com>
To: "ext Graham Klyne" <Graham.Klyne@mimesweeper.com>
Cc: <w3c-rdfcore-wg@w3.org>


--
Patrick Stickler, Nokia/Finland, (+358 50) 483 9453, patrick.stickler@nokia.com
 
----- Original Message ----- 
From: "ext Graham Klyne" <Graham.Klyne@mimesweeper.com>
To: <Patrick.Stickler@nokia.com>
Cc: <w3c-rdfcore-wg@w3.org>
Sent: 05 September, 2002 15:56
Subject: 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.

That was proposed, but I do not believe it represents the concensus
that the restructured document attempts to capture.

Patrick

> 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 09:18:23 EDT

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