Review of Datatyping content in Primer

Frank,

Here are my comments from reviewing the Primer with regards
to datatyping.

All in all, looks great. Only one critical comment:

In section 2.5, you should move

a.. Each literal (member of the datatype's lexical space) is associated with exactly one member of the datatype's value space (so
that, given a datatype and a literal, there is no ambiguity in which value is meant).

to the set of required conditions. The N:1 L2V mapping is not optional.

That N > 0 is now not a requirement, even if the usual case, as
pointed out for XML Schema union datatypes, is the only recommended
but optional condition.

Note that the N:1 mapping is still true for a union datatype. Lexical forms
are not shared between values. Even if separately the lexical form
will map to different values for each datatype, once merged into a
union datatype, all but one datatype's L2V mappings are "neutralized"
and a given lexical form, for the union datatype, maps to one and only
one value.

The N:1 mapping condition is absolutely critical to RDF datatyping. It is
not optional.

--

Some minor comments:

1. In the examples showing how typed literals are expressed in RDF/XML,
you may want to use URIrefs for the datatypes in both the N-Triples
notation and the RDF/XML so that it is clearer how they relate. The
N-Triples in those examples presently use qnames, and the reader may
forget which qnames relate to which URIrefs, etc. I see that you
point out the use of qnames in the triples as opposed to URIrefs in
the RDF/XML, but using them in both places may be clearer anyway.

2. After introducing typed literals and datatypes, you say
"For the most part, we will continue to use XML-style (untyped)
character literals in our examples.". It seems to me that if the
intuitive semantics of the subsequent examples are datatype
values, that typed literals should be used. This will also encourage
new RDF users to use the richer, more explicit expression provided
by typed literals rather than the more ambiguous and (now given
string-based semantics) misleading untyped literals. Leaving the
examples including e.g. dates, weights, etc. as string-literals
reflects bad practice, IMO, given the new datatyping machinery.

3. In section 5.2, you write

   "The rdfs:range property can also be used to indicate that the value of
    a property is intended to be a literal of a particular datatype.
    For example, if we wanted to indicate that the property ex:age was intended
    to be a literal of the XML Schema datatype xsd:integer, we would give the
    property) resource ex:age an rdfs:range property whose value is the
    resource xsd:integer."

This might be better stated as something akin to

   "The rdfs:range property can also be used to indicate that the value of a
    property is intended to be a datatype value denoted by a typed literal.
    For example, if we wanted to indicate that the property ex:age was intended
    to be a datatype value of the XML Schema datatype xsd:integer, we would give
    the property) resource ex:age an rdfs:range property whose value is the
    resource xsd:integer."

I.e. datatypes don't have literals, they have values and lexical forms.

4. Your "intended to be" language for rdfs:range may suggest a bit too
strongly the deprecated idea of constraints rather than the new view
of assertions. Perhaps you could say "presumed to be", e.g.

    "The rdfs:range property is used to indicate that the values of a
     particular property are presumed to be instances of a designated
     class."

You might even point out that they are actually taken to be assertions
about the rdf:type of the property values, and that the following
entailment holds

   some:Property rdfs:range some:Class .
   some:Thing some:Property some:Resource .

entails

   some:Resource rdf:type some:Class .

[though of course, the entailment can't be expressed for typed literals,
 but the semantics hold all the same]

--

That's all.

Cheers,

Patrick


[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]

Received on Monday, 4 November 2002 04:56:40 UTC