comments on the current clutch of working drafts

Comments on the Syntax Specification:

In general the new syntax specification is a giant step forward.  It
finally makes RDF/XML real XML.  

I do not understand why the information set nodes are transformed into a
sequence of events, however.  Why not just work directly on the information
set nodes?

Problems and Specific Comments:

1/ The rule for abbreviation of string-valued properties (Section 2) is not
   correct, because of the XML requirement that attributes names be unique
   within an XML element.

2/ How is base-uri set from the root node?  If this is part of the infoset
   model, it should be mentioned.

3/ The semantic action for an empty subject on a nodeElement could be
   executed even for element nodes with an rdf:ID or rdf:about attribute.
   This is probably benign, but would cause the blank node identifier
   generator to be pointlessly run, resulting in distinct (but
   model-theory-equivalent) sets of n-triples resulting from a single
   RDF/XML document.n

4/ The constraint on only one rdf:ID (or rdf:bagID) for a URI in a given
   document is hidden deep in the document.  It would be much better to
   gather all these context-sensitive constraints in one place.  It would
   be even much better to remove these context-sensitive constraints, as
   there is no need to have only one rdf:ID with a particular URI in a
   document.  The development of this constraint is rather confusing, as
   there have been statements to the effect that rdf:about="#foo" is a
   synonym for rdf:ID="foo".



Comments on the Model Theory:

The model theory makes it very clear that RDF reification is not related in
any way to reificiation.  This is good, but does raise the issue of why
reification has been retained.

The model theory, along with the recent decision allowing multiple rdf:_<n>
statements in containers for a particular <n>, makes it very clear that
rdf:Seq is not related to sequences, rdf:bag is not related to bags, and
rdf:Alt is not related to alternatives.  This is again good, but does raise
the issue of why these have been retained.

The theory of literals in the model theory is very weak.  This means that
there is no relationship whatsoever between literals the differ only on
their language (or on the presence of a language).



Comments on RDF Schema:

No comments from me.




Comments on the Primer:

1. Introduction

The primer starts 

	The Resource Description Framework (RDF) is a general-purpose
	language for representing information in the World Wide Web.

OK, let's take this at face value.  How can I, in RDF, represent the
information that right now either it is Tuesday or the sun is shining?
Well, I can't, of course, because RDF is not a general-purpose language for
representing information.  Instead RDF is a special-purpose language for
representing some limited kinds of information.   

The first example in the primer continues this sort of overstatement.  The
example contains the RDF statement (in n-triple format)

  <http://www.w3.org/People/EM/contact#me> <personalTitle>
  	"Semantic Web Activity Lead" .

and claims that this can be read as that there is ``someone who is the
Semantic Web Activity Lead''.  Well, this is not a reasonable reading of
this n-triple.  A much better reading would be that there is ``someone
who's personalTitle is "Semantic Web Activity Lead"'', quite a different
reading entirely.

The primer mentions ``RDF Schema (and datatypes)'' but there is no treatment of
datatypes in the primer.

2. Making Statements About Resources

This section moves from the very grandiose claims of the Introduction to
much more defensible descriptions of what RDF can do.  The beginning of
this section would make a decent introduction section.

The repeated use of ``a creator whose value is'', and similar constructs,
are difficult to parse.  As the statement that is being produced here has a
URI for the creator, it should be possible to just use ``a creator who
is'', a similarly in several other cases.

The use of ``temporary identifier'' for blank nodes is wrong and, moreover,
misleading.

3. An XML Syntax for RDF

It is not possible to use namespaces for the URI labels for object nodes,
except (sometimes) for the labels of types.  In general, only edge labels
can employ namespaces.  This is illustrated in the example RDF/XML syntax,
which does not use namespaces for http://www.example.org/index.html.

The abbreviation example incorrectly states that rdf:resource is (always)
used when ``the property value is another (existing) resource''.  There
are, instead, lots of ways to do this in RDF/XML.

This section retains the notion that rdf:about is used for existing
resources and rdf:ID is used for new ones.  This is not correct.

The example for parseType="Resource" misleadingly implies that an rdf:ID
attribute here would provide a name for the resource.  Instead an rdf:ID
attribute here is a reification mechanism.

4. Defining RDF Vocabularies: RDF Schema

This section give the impression that RDF Schema is nothing more than a
well-known set of names, to be used in RDF.  Instead RDF Schema is a
semantic extension to RDF.  This section blurs the distinction between RDF
and RDF Schema, particularly in its treatment of rdf:type.

This section is confused about classes.  In one place it states that
classes are defined as those resources ``whose rdf:type property has a
valud which is the pre-defined resource rdfs:[C]lass''.  In the next
paragraph, it states that ``Individual classes [...] will always have an
rdf:type property whose value is rdfs:Class (or some subclass of rdfs:Class
[...])''. 

5. RDF Containers

This section dramatically overstates the abilities of RDF containers.  This
is only partially remedied by the caveats near the end of the section.


Overall comments:

The lack of any treatment of datatyping in RDF (except for a few mentions
that state that datatyping is deferred to the future) is surprising, and
disappointing, particularly in light of the mention of XML Schema datatypes
in the RDF Core WG charter.  However, no treatment of datatypes is better
than a bad treatment of datatypes.

Received on Tuesday, 21 May 2002 17:01:26 UTC