Re: A data typing proposal

On 2002-07-31 3:12, "ext R.V.Guha" <guha@guha.com> wrote:

> 
> Hi all,
> 
>  Given the amazing progress we have made on agreeing on the one right
> way of dealing with data types, here is a proposal that is only
> partially tongue-in-cheek.
> 
> Lets face it ... there isn't that much RDF out there. I am sure that
> in their spare time, the Dans and Pats of the working group could easily
> rewrite it all. So, a clean solution that breaks some existing RDF files
> might be worth considering.
> 
> The simplest thing I can think of is to say that the literal always
> denotes the string, unless there is an explicit xsd attribute which
> specifies some other data type. Life just becomes so much simpler ...
> 
> guha
 

Guha, as far as I know, there is full concensus on local datatyping,
both for the idiom and its meaning. The issue of debate has always
been the global/implicit idiom -- or how one may assert datatyping
constraints or assertions for all values of a property, and
how such constraints/assertions relate to implicit/untyped literal
values.

I.e, how do we define something such as

   Jenny ex:age "10" .
   ex:age rdfs:range xsd:integer .

so that "10" in this case either denotes the integer value 10 or at
least in some way consistently and unambiguously "communicates"
the assertion that Jenny has an age of 10 (not "10").

I.e. the whole issue is how to have something akin to rdfs:range,
or how to use rdfs:range itself, with inlined literals where there
is no local typing defined for the particular occurrence of the
literal itself.

Note that this datatype constraint mechanism is also relevant even
if there is local datatyping, just as rdfs:range is relevant if
there is an explicit rdf:type statement about some resource.

E.g.

   Jenny ex:age _:x .
   _:x xsd:integer "10" .
   ex:age rdfs:range xsd:integer .

I agree that we should not get too hung up on possibly breaking
a few implementations out there -- if it is clear that the result
is a substantially better solution -- but we also need to provide a
solution to datatyping range constraints/assertions which works
well with the local typing mechanism as well as (ideally) present
RDF/S mechanisms.

Taking literals as tidy simply punts on datatyping for inlined literals.
Given that inlined literals represent the lion's share of usage, that
seems unacceptable to me (and I think many others as well).

Taking literals as untidy, being akin to bnodes with context dependent
labels, allows us to use rdfs:range for datatyping with no change
to its present semantics, and also means that if/when literals are
permitted to be subjects, RDF datatyping will be no different
from general RDF/S typing, using rdf:type statements with literal
subjects rather than the datatype property idiom to assert local
typing.

This simply means we use the existing mechanisms provided by
rdfs:range and rdf:type for datatyping, though for the moment, we
have to use the datatype property idiom since literals can't
be subjects. Otherwise, it's no different than current RDF typing.
The particular mapping issues between lexical forms (literals) and
datatype values remains fully external to RDF and is born by the
(external) semantics associated with the datatype URI.

I would say that that is far more simpler.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Wednesday, 31 July 2002 04:23:10 UTC