W3C home > Mailing lists > Public > www-rdf-logic@w3.org > July 2002

Re: Dataypes, literals, syntax

From: pat hayes <phayes@ai.uwf.edu>
Date: Sun, 28 Jul 2002 22:53:30 -0400
Message-Id: <p05111b02b96a5c30da52@[]>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: www-rdf-logic@w3.org

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

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.

>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

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Monday, 29 July 2002 10:11:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:38 UTC