From: Peter F. Patel-Schneider (email@example.com)
Here are my (initial comments) on the RDF WDs. I'm willing to collaborate with others to jointly come up with a joint response from the joint committee. :-) peter 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? 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. 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 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 the 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 namspaces. 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 no longer correct, nor is it the case that there must be at most one rdf:ID for a given URI in a document. The example for parseType="Resource" misleadingly implies that an rdf:ID attribute here would provide a name for the resource. Instead an rdf:ID 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. Comments on RDF Schema: 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.
This archive was generated by hypermail 2.1.4 : 05/15/02 EDT