Re: Dataypes, literals, syntax

From: pat hayes <phayes@ai.uwf.edu>
Subject: Re: Dataypes, literals, syntax
Date: Sun, 28 Jul 2002 22:53:30 -0400

[...]

> OK, I see. But I don't see the real utility of the suggestion in this 
> case. It provides no extra expressive ability; at best it saves a 
> triple here or there; but on the other hand it complicated the 
> syntax. So this is a syntactic trade-off, and I guess I think that on 
> balance its not worth the trouble. We can get the same effect by 
> using a bnode and an extra triple, in effect writing the typed 
> literal as a triple:


Well, how about compatability with XML Schema?  I mean is it not important
to be able to write

<ex:foo>
  <ex:bar xsi:type="xsd:integer">10</ex:bar>
</ex:foo>

If not, then what is the relationship between the XML standards and RDF
good for?

[...]

> >Ignoring that,
> >what is problematic about this example?
> 
> Its not semantically problematic, but it does mean that datatyping 
> would have to be built into RDF even at a very basic level. I guess 
> this could be considered an advantage, but it doesn't fit very well 
> into the zeitgeist of the core WG.

How is the above scheme any more built-in than the schemes being considered
by the RDF Core WG?  They both depend on datatype mappings, don't they?

> >  The model theory would say that
> >the denotation of xsd:integer"10" is the member of the XML value space that
> >is the result of the XML Schema datatype integer lexical-to-value mapping
> >of the string "10", i.e., the integer 10.  Similarly, the model theory
> >would say that the denotation of xsd:octal"12" is the member of the XML
> >value space that is the result of the XML Schema datatype octal
> >lexical-to-value mapping of the string "12", i.e., the integer 10.  This is
> >no different from how any of the proposals put forward by the RDF Core
> >Working Group would have do work.
> >
> >>  Pat
> >
> >In sum, I don't see any downsides to having typed literals, only upsides.
> 
> I guess I disagree. I see no clear upsides, and several downsides. 
> Chiefly, I see extra syntactic complexity in the basic spec, for no 
> real advantage in expressiveness or efficiency. Basically, small 
> constant factors in numbers of triples are not worth bothering with.

I see much more complexity in the RDF Core WG proposal.  It requires bnodes
and explicit mappings. 

> >It is the way XML (Schema) handles typing of literals;  it allows an escape
> >from some of the problems with XML Schema datatypes having to do with union
> >datatypes
> 
> I fail to see how it helps there.

You can locally type in the syntax to allow "10" to be either an integer or
a string if the range type is a union type.

> >; it provides a clear and clean way of locally typing literals;
> 
> We already have one of those (the datatyping property idiom)
> 
> >it avoids the extra blank node junk in the RDF Core Working Group current
> >treatment of local typing.
> 
> Extra blank nodes are harmless. RDF is chock-full of this kind of 
> 'junk' in any case. Tiny improvements in elegance are irrelevant.

Well, I disagree very much here.  I don't see where RDF has this kind of
junk, except in reification and containers, which can be avoided in most
cases.  Requiring junk to do datatyping makes it much harder to avoid the
junk.


peter

Received on Monday, 29 July 2002 17:23:16 UTC