Re: Dataypes, literals, syntax

>From: pat hayes <phayes@ai.uwf.edu>
>Subject: Re: Dataypes, literals, syntax
>Date: Fri, 19 Jul 2002 16:22:06 -0500
>
>>  >From: "Jonathan Borden" <jonathan@openhealth.org>
>>  >Subject: Dataypes, literals, syntax
>>  >Date: Fri, 19 Jul 2002 08:56:02 -0400
>>  >
>>  >>
>>  >>  I just noticed:
>>  >>  http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Jul/0121.html
>>  >>
>>  >>  It got me thinking about literal datatypes (the above considers XML
>>  >>  datatypes).
>>  >>
>>  >>  Why not:
>>  >>
>>  >>  <rdf:Description rdf:about="foo://bar">
>>  >>      <ex:property xsi:type="xsd:integer">10</ex:property>
>>  >>  </rdf:Description>
>>  >>
>>  >>  being defined to parse to:
>>  >>
>>  >  > <foo://bar> ex:property xsd:integer"10" .
>>  >  >
>>  >>  wouldn't this solve much of the datatypes debate -- it would 
>>_syntactically_
>>  >>  distinguish typed literals, as Drew McDermott correctly points 
>>out is the
>>  >>  way to go, and would avoid issues related to nonmonotonicity related to
>>  >>  interpreting a triple based on a schema that may or may not be present.
>>  >
>>  >This has been proposed several times, by several people, including myself,
>>  >most recently in
>>  > 
>>http://lists.w3.org/Archives/Public/www-rdf-comments/2002JulSep/0024.html
>>  >The RDF Core WG has, for some reason, chosen not to accept this in any
>>  >guise, even as part of a datatyping facility for RDF.
>>
>>  One reason is that (as far as I can see; correct me if Im wrong here)
>>  this proposal does not allow non-datatyped literals.  That (very
>>  strong) constraint seems unacceptable for RDF and would clash with
>>  established usage.
>
>There is nothing in this approach that would *prevent* untyped literals.
>Literals could be as above, i.e., typed, or just strings, i.e., untyped.
>
>This approach could be teamed with a treatment of untyped literals as
>denoting an element of an opaque type; it could be teamed with a treatment
>of untyped literals as denoting strings; it could be teamed with a
>treatment of untyped literals as syntactic constructs whose denotation is
>underspecified and that can be further constrained by, for example, range
>statements.  (The last treatment, of course, has its own problems, but they
>are exactly the same as they would be without typed literals.)
>
>>  In a related criticism, it does not (again, please
>>  correct) allow for 'remote' datatyping, where the association of a
>>  datatype with a property range imposes a datatype interpretation on
>>  uses of the property in other statements.
>
>Agreed.  Typed literals are typed.  But so what?  If you want to have
>undertyped literals then you can also, as shown above.

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:

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

>  > As an example of a problematic inference, consider whether
>>
>>  <foo://bar> ex:property xsd:integer"10" .
>>  <foo://baz> ex:property xsd:octal"12" .
>>
>>  should or should not entail
>>
>>  <foo://bar> ex:property _:xxx .
>>  <foo://baz> ex:property _:xxx .
>>
>>  and how this could be detected by a reasoner.
>
>Well, first of all xsd:octal is not an XML Schema datatype.

Right, but you get the point.

>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.

>  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.

>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.

>; 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.

>
>peter
>
>PS: If people are *really* interested in trying to have something like this
>in RDF, I can polish up and update one of my previous proposals along this
>line.  I may even have a up-to-date proposal lying around somewhere, but
>I'm not going to put more work into it without some hope of having some
>impact.


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Monday, 29 July 2002 10:11:57 UTC