RE: new datatyping proposal

> Jenny --ageYears--> int_5
> 
> I(xsd:integer) = {I(int_0), I(int_1), ... }

To have to define a lexical grammar for the constants of
typed literals which further have a lexical grammar for
the lexical form portion is not practical at all.

The graph syntax representation of a typed literal should
be the fusion of the URI denoting the datatype and the
lexical form, the lexical grammar of which is defined
by that datatype.

While I consider this to be a tangient from what the WG
should be focusing on regarding datatyping, I'm not opposed
to the idea of having typed literals as an additional
atomic element of the graph syntax -- *but* its representation
should not require any further specification beyond the URI
identity of the datatype and the lexical grammar of the 
datatype itself.

> It is the intent that at least some of these data types (like 
> integers, 
> floats and strings) correspond to data types provided by programming 
> languages and storage systems, so as to allow for efficient 
> storage and 
> retrieval of RDF.

Nothing prevents that with the previous proposals. This is a
trivial implementational issue that has no relevance to the
abstract graph syntax.

It is to be expected that APIs and other RDF applications will
provide abstractions of datatyped values based on their idomatic
expression in the graph. So what. That is true for all of the
proposals that have been on the table thus far. The benefit
asserted here is an illusion. Whether the application interns
based on typed literal constants, multi-node idioms, or any
other representation, it's all the same, and no alternative
is not significantly better or worse than any other.

> [[We can either leave the literal as an opaque thing in the 
> graph syntax 
> and model theory or we can try to capture the type 
> information, e.g., by 
> means of 4-tuples]]
> 
> 
> 2. Concrete syntaxes
> --------------------
> 
> In the RDF/XML syntax, non-string literals are encoded in accordance
> with the XML Schema spec as
> 
> <propName xsi:type="URI">XML content</propName>

Again, I understand xsi:type to be tied to XML Schema datatypes,
not to arbitrary datatypes, therefore adoption of this term
constitutes treading on other folks front lawn.

Likewise, if it the case that 'int_5' is of rdf:type xsd:integer,
i.e. that it denotes the value five, then we can just as well
use rdf:type instead of xsi:type.

> RDF/XML parsers provide callbacks that allow generating a compact
> internal representation of literals that correspond to data types
> provided by programming languages and storage systems (e.g., integers,
> floats and strings). Similarly, the serializers provide callbacks for
> encoding such literals in RDF/XML.

These are all simply implementational issues that can also be
done for any of the proposed datatyping idioms. We are not tasked
to say how RDF parsers and APIs are to be implemented. There
are many ways to optimize the internal storage of RDF expressed
knowledge.

> we have to enumerate a minimal set of
> (XSD) types that are required to be supported by RDF applications.

This is neither acceptable, nor necessary.

(a) there is alot that can be done without recourse to datatype
    processing, so requiring it raises the bar substantially
    for RDF applications unnecessarily

(b) there is no actual need to create this dependency between
    RDF and XML schema datatypes or any native set of RDF datatypes,
    as several (if not all) of the previous proposals have 
    clearly demonstrated

--

This proposal is not offered as a solution to any fatal flaw
in the local datatyping mechanisms outlined in the latest
datatyping WD (the stake-in-the-ground proposal), and IMO
is a less optimal solution that the present stake-in-the-ground
proposal.

It also fails to address global typing and the relationship of
datatyping to RDF types in general.

I do not see this as an acceptable solution to RDF datatyping
and do not feel it is worth the WG's continued time and energy
to pursue.

I recommend that the WG return to the stake-in-the-ground
proposal, make a decision regarding the tidyness/untidyness
of literals as defined therein, and task the editors to 
complete the WD for publication.

Patrick

Received on Thursday, 8 August 2002 08:26:33 UTC