Re: Review of Datatyping content in Primer

Patrick--

Thanks for the comments.  Some observations about them:

Patrick Stickler wrote:
> 
> 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.
> 

I take your point, and I can certainly move the condition up to the
preceding set of bullets (which are not explicitly designated as
"required", although that could be changed).  However, to what extent do
you think RDF can actually impose and test these requirements?  In other
words, it seems to me that someone can create a typed literal and cite a
URI for the datatype, with no guarantee that the datatype actually meets
these conditions.  How does RDF validate the requirement you are talking
about?  We might say that if the datatype *doesn't* satisfy these
conditions, things are going to get screwed up, but that's not the same
statement.

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

I'll see what it looks like.  The problems with ful URIrefs in triples
is that the triples run off the page, and that is *really* not clear!

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

Part of this is lack of time and/or laziness.  I didn't have time to go
through all the examples and change them.  
Another part of this is not wanting to make the RDF/XML look any worse
than it already does.  People bitch about how convoluted this looks as
it is;  before adding all those type URIs to the elements, I want to
have time to buy some stock in whiskey distilleries, as I would expect a
run on the bottle.

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

Sounds good.

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

I think that what's deprecated about constraints is that they are the
*only* way of interpreting these Schema declarations.  I still think
they are the most likely use.  I tried to explain this business rather
explicitly in Section 5.3;  I'm not sure I want to convey this via what
is an awfully subtle distinction between "intended" and "presumed".  
 
> 
> 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

The only place the word "entailment" appears in the Primer is in the
discussion of the Test Cases document.  If it appears anywhere else,
it'll be a mistake (it might be a mistake where it is now too!). 

--Frank

-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752

Received on Monday, 4 November 2002 13:43:49 UTC