review of LCC documents as of 26 December 2002

Integrated Review of the RDF Core WG LCC Documents (as of 26 December 2002)


This review is the result of reading the RDF Core WG LCC Documents as they
existed on 26 December 2002.  I read the documents in the order they were
listed on the RDF Core WG page - Primer, Concepts, Syntax, Schema,
Semantics, and Test.  All except Schema were listed as last call candidate
versions.

It would be better if the documents had a consistent naming scheme.

Summary:

Lots of misleading statements.  Quite a few actual errors and unsupported
claims.  At least one fatal flaw that would prevent the use of RDF by just
about any organization.


RDF Primer (Editor's Draft of 17 December 2002)

Summary:

A Primer need not be comprehensive, so remove the portions that deal with
difficult RDF stuff.  A Primer needs to be more than correct, so fix the
errors and misleading portions, particularly about the use of URI
references and the meaning of RDF. 

Section 1:

The RDF Primer starts with a serious organizational mistake.  It repeats
much of the abstract verbatim in its first two paragraphs.  This leads one
to consider just how much care has gone into the rest of the Primer. 

The first section of the Primer is very confused as to what RDF actually
is.  It states ``RDF is a language'' but then goes on to also state that
``RDF also provides an XML-based syntax''.  How can a language provide
anything? 

The Primer states that RDF is based on the idea of representing things
using URIs, but the very next example uses non-URIs (literals).   The text
after the example admits the use of non-URIs, but in a clunky and confusing
fashion. The first also example doesn't mean what the accompanying text
says because it uses a URI where a blank node is called for. 

The Primer uses the word simple several times, but fails to give any
support to the use of the word.  

The role of the Primer is stated in a rather silly fashion.  If the Primer
is supposed to augment the other documents, then how can it be a Primer?
It would have been much better to state that the Primer provides a
non-normative introduction and/or high-level description of  parts of RDF. 

Section 2:

If the Primer is supposed to be an introductory document, then
constructions like ``simple way to state properties (make assertions
about)'' are not very helpful.  An introductory document should not have
such parenthetical remarks.  Similarly an introductory document should have
simple, and correct, sentence constructions, so turning a complete sentence
into a parenthetical sentence fragment is bad on two counts.

The first extended example in this section also has serious problems.
First, the text description does not match the boxed sentences.  The text
description talks about the name of the creator, whereas the first boxed
sentence does not.  This is a particularly bad mistake to use because of
the similar problems with the Dublin Core use of  RDF.  This example also
is confusing because the boxed sentences use URIs for subjects, but
non-URIs for predicates.  If the boxed sentences are supposed to evoke RDF
triples, and it sure looks as if they are, then they should at least evoke
valid RDF triples.  It would be better to not talk about web pages in the
examples, so this sort of problem would not occur.  

Not using web pages in the early example would also not give rise to the
problems related to how to dereference a URI reference in RDF.  This
problem is pervasive in much of the non-formal document on RDF.  The
general problem is that the relationship between the RDF meaning of a URI
reference and the WWW meaning of a URI reference is very poorly determined
for URI references that actually have a well-defined WWW meaning.  For
example, http://www.w3.org/People/EM/contact#me (probably) references an
actual portion of an actual document.  How then can RDF treat URI reference
as referring to the person Eric Miller?  Because the Primer has examples
that have this problem, it needs to address it. 

The Primer is not consistent with the other RDF documents.  It states that
a resource is anything that is identifiable by a URI reference.  However,
the model theory for RDF does not make this extraordinarily strong
assumption, only requiring that URI references denote resources.  The
Primer also states that URI references can identify ``practically
anything'', a laughable claim to anyone who understands the difference
between countable and uncountable sets. 

In Section 2.2, the problem with referring to web documents resurfaces.
The Primer states that it is ``introducing'' the URIref of the web
document.  However, that URIref was already in the statement, and so cannot
be considered to be introduced here.  

Although the Primer is non-authoritative, it should refrain from making
false statements, such as that the subject and object of an RDF statement
are labeled with URIrefs.  Only some subjects and objects are labeled with
URIrefs.  The Primer goes on to immediately use RDF statements whose
subjects are literals, in direct violation of the claim it makes just
above. 

The example in Section 2.2, inappropriately glosses over the issue of
whether to turn the object of a statement into a URIref or a literal.  It
is inappropriate to gloss over this issue because the example does both,
without any explanation at all. 

The claim that RDF graphs are labeled directed graphs is not very helpful,
as labeled directed graphs generally allow only one arc between two nodes.
If the Primer wants to allude to graphs, it should be more precise. 

The Primer starts the unfortunate blurring between RDF, a simple formalism,
and the entirely of human understanding in its talk about knowing the
``exactly what is meant by'' http://purl.org/dc/elements/1.1/creator.  It
would be much better to avoid anything in the Primer that even hints that
an  RDF processor will be able (or, worse, required) to understand exactly
what is meant by such things, as their meaning includes a gigantic portion
that is outside of RDF. 

Similarly, the Primer should stay far away from hinting that RDF can be a
unifying model for formal logic.  Although all that is actually claimed is
that RDF is similar to simple statements in formal logic, the overall tone
of the paragraph could easily give rise to a false expectation. 

Section 2.3 finally gets into the issue of whether something is a literal
or not.  This would be fine if the earlier exposition had not set the stage
so misleadingly.  Similarly, Section 2.3 finally mentions the problem of
using the wrong URIref to refer to a non-web-accessible resource.  Again,
however, the previous parts of the Primer have already given the wrong
impression about this important issue. 

Section 2.4 misses a golden opportunity to clear the air about typed and
untyped literals.   It should have drawn attention to the fact that the
untyped example makes ages be strings, not numbers, and that treating these
strings as numbers is a risky business, depending as it does on an
outside-of-RDF interpretation of RDF information that undermines the
utility of RDF as a neutral mechanism for information exchange. 

Emphasizing and reemphasizing that datatypes are an extension to RDF begs
the question of whether RDFS is an optional extension or part of RDF.  If
the Primer is going to be so picky about datatypes, then it should be
similarly picky about RDFS. 

Section 3:

RDF has no notion of the source of terms.  As far as it is concerned a
URIref is an atomic entity with absolutely no internal structure.  That
being the case, any statement that even hints at the contrary must be
ruthlessly expunged from the RDF documents.  In particular, stating that a
namespace declaration provides the source of a term is not a part of RDF ?
namespace declarations are nothing more than an abbreviation mechanism for
XML/RDF. 

It is somewhat misleading to describe the abbreviated syntax forms as
abbreviations.  Instead they are really alternative syntax forms that have
their own direct mapping to triples, they just happen to be shorter than
the standard syntax form.  If they were abbreviations, then their meaning
should instead be given by a source-to-source translation. 

One would think that a Primer would provide exemplary examples.
Unfortunately, this primer does not, instead ignoring opportunities to
effectively use typed literals.  The Primer even makes this into somewhat
of a joke, asserting that ``typed literals from appropriate datatypes, such
as XML Schema datatypes, can always be used instead.'' 

The Primer makes an interesting point when it states that ``RDF doesn't
specify or control how URIrefs are assigned to resources''.  This point is
a foundation of the RDF model theory.  However, the Primer and many of the
other RDF documents both undermine this point, by evoking an
external-to-RDF mapping between URIrefs and resources, and completely
contradict it, by using a URI to identify the web document that it
references.  The Primer makes another interesting point when it states that
``anyone should be able say anything they want about existing resources''.
However, other documents about RDF attempt to limit the ability to make
statements about existing resources in various ways or limit the ability to
use certain URIrefs. 

Section 3 is supposed to be about XML/RDF.  However, it introduces
rdf:type.  It would be very much better if this important concept were not
introduced inside the section on XML/RDF.  (The forward reference
concerning rdf:type in Section 2 is also a bad idea.) 

Section 4: 

A Primer need not be complete.  Being that this is the case, there is no
place for the difficult-to-understand or insufficiently-specified parts of
RDF in the Primer.  (I was going to say ``junk'', but nobly refrained.)
Removing Sections 4.1 and 4.3 would make the Primer much better. 

If Section 4.1 is retained, it needs to be completely rewritten.   The
continued reference to ``intended'' meaning is just silly.  It would be
much better to come right out and say that containers are just
uninterpreted conventions that can be given any meaning whatsoever by
applications, but that there is some vague notion that this meaning should
be somehow related to bags, sequences, or alternatives.  In particular,
having examples where the same predicate is used to relate to individuals
as well as to a bag containing the individuals is more than misleading.
Presenting such misrepresentations in a Primer is a disservice to the RDF
community.  Similarly making a committee be a bag is misusing even the weak
intended meaning of bags.  A committee is not a bag of its members. 

Section 4.3 also needs a complete rewrite.  It perpetuates the old RDF myth
that instances of  rdf:Statement have something to do with RDF statements.
There is just no way in which an instance of rdf:Statement can be
considered to be a model of an RDF statement.  There is also no notion of
reification supported by RDF.  This is only made worse by the attempt to go
from RDF statements to particular instances of RDF statements, a notion
that exists nowhere in RDF.   If a notion is not part of RDF, then the
Primer has no business talking about it. 

Section 4.4 is also suspect in the same way as Sections 4.1 and 4.3, but to
a lesser extent.  

If any of the stuff in Sections 4.1, 4.2, and 4.3 are to be included in the
Primer it would be much better to relegate them to some dusty appendix,
perhaps called ``Conventional Ways of Using RDF''.  This appendix could
also discuss things like using collections of triples to represent
structured values or n-ary relationships. 

Section 5: 

Can RDFS be used to ``specify'' anything?  Not really.  Instead, RDFS
allows one to build a sort of a primitive type theory for a domain.  Saying
that RDFS is a specification language does a grave disservice to true
specification languages. 

Describing inference as the ability to ``act as if'' is not a particularly
correct description. 

Generalization hierarchies are generally written with the more-general
classes above the less-general classes. 

The general idea of the section about the use of schema-supplied
information is good, but the emphasis is placed in the wrong place.
Instead it would be better to state something like applications may choose
to use schema-supplied information to limit the kinds of data they generate
outside of RDF so that it explicitly conforms to the schema.  The third
example here is the worst one because it uses non-datatype inconsistency a
notion alien to RDF.   The next paragraph is simply wrong, as there is no
notion in RDF that allows for invalidity due to the absence or presence of
properties. 

It would be better to state something like that rdfs:comment and the other
non-logical RDFS properties are used only  conventionally, and completely
externally to RDF.  Nothing in RDF requires that they be used for their
conventional purposes.  The phrase ``can be used'', although it is
technically correct, is very misleading here. 

Section 7:

Here again we see wording to the effect that the meaning of an RDF graph
can be conveyed by any mechanism whatsoever, including in principle the
inaccessible thoughts of a deceased creator of some web page that contains
some RDF/XML.  Although it is true that any formal system will have an
intended meaning that is outside the formal system itself, it is a bad idea
to give this intended meaning the status that is being given to the
non-model theory meaning of RDF.   Doing so is an open invitation for
applications and users to claim that their intended meanings for their RDF
documents are part of the official meaning provided by RDF.  

Separating RDF meaning into a formal and a social part will do nothing to
prevent this.  About the only way to mention intended meanings in the RDF
documents without legitimizing this meaning-bloat would be to explicitly,
strongly, and continually mention that the non-formal meanings given to RDF
documents in applications are not a part of their RDF meaning. 

References 

It is very weird that a non-normative document has normative references! 

Appendix A 

Finally, some discussion of the problems with referring to web pages.  If
only the advice here was taken in the body of the document. 

 
Resource Description Framework (RDF): Concepts and Abstract Syntax
Editors' Working Draft 12 December 2002
 
The notion of what is and what is not normative in this document is very
poorly specified.  I have been told several times that the definition of an
RDF graph in the document is normative, but yet this section is not marked
as being normative.  I suggest that each section of the document be clearly
marked as normative or non-normative.  The document contains quite a number
of errors and misleading pieces that need to be fixed.  It also contradicts
itself in a number of places. 

Abstract 

I seem to remember learning that ``This document'', etc., are not to be
used in an abstract.  I only mention this here because the abstract is
otherwise so good, being concise and to the point.  Its only other flaw is
the superfluous paragraph division.  After the excellent abstract, however,
this document commits the cardinal sin of repeating the abstract at the
beginning of the document itself.   

Section 1: 

After the excellent abstract, however, this document commits the cardinal
sin of repeating the abstract at the beginning of the document itself.   If
you say the same thing twice, you should at least have the decency to say
it in different words. 

Just what is the RDF core?  Is there something else to RDF besides the
core?  If so, what, and which W3C documents address it?  If I was going by
the document list, I would be forced to conclude that the semantics for
RDFS were in the core, but RDFS itself was not - a very strange state of
affairs.  RDF datatyping would fall within the core, which is again strange
because it depends on RDFS. 

I would be careful to spell out RDF wherever it is referred to, and avoid
short forms such as ``the formalism''.  The notion of layering here is also
very strange.  There is a distinct difference between the relationship
between RDF and DC and RDF and OWL. 

Section 2: 

This section starts out with a very clear definition of RDF:   ``RDF has an
abstract syntax that reflects a simple graph-based data model, and formal
semantics with a rigorously defined notion of entailment providing a basis
for well founded deductions in RDF data.''  If only the RDF documents
actually followed this definition of RDF, instead of swerving out to
include ``intended meaning'', ``social meaning'', and the like. 

The list of uses in the motivations section has just about the best example
of non-parallel construction that I have ever seen.  The list of design
goals is, however, a very close second.  It wouldn't take much effort to
make these lists infinitely more readable. 

In the list of goals, there is, again, the statement that RDF is supposed
to be able to support assertions about anything.  This goal runs counter to
several efforts to restrict the ability to state assertions about
particular resources.  The list of goals also has the very strange goal
that RDF is supposed to be a basis for legally binding agreements.  What
part of RDF is going to be able to support this goal? 

Why not give up on the term ``data model''?  It just causes confusion when
compared to model theory. 

Why are literals in RDF if  ``URI references are used for naming all kinds
of things in RDF''? 

Inconsistency is a technical term.  It would be best not to use it in
informal settings, instead talking about false or incorrect statements.  As
RDF has only a very limited notion of inconsistency, and then only with
respect to datatypes, it is misleading to say that applications build upon
RDF have to be able to deal with conflicting information. 

Why not give a quick glimpse of what a simple fact is here instead of using
a bare forward reference?

  
Section 3: 

Are the concepts in Section 3 supposed to be exhaustive in some sense?  It
almost seems as if they should be, yet there is no indication of whether
this is the case. 

The RDF Primer says that RDF graphs are labeled directed graphs.  This
document says that the ``underlying structure of any expression in RDF can
be viewed as a directed labeled graph''.  Neither is correct because RDF
graphs are not really labeled directed graphs as they are usually defined,
but one would think that at least the same term could be used. 

Just what is an RDF graph?  As this is supposed to be the normative
definition of an RDF graph, one would think that an absolutely correct
definition would be given here.  However, instead one finds that an RDF
graph is a set of triples, followed by a diagram that doesn't look like a
triple, followed by a quasi-definition of  something called a ``property
arc'', followed by the claim that an RDF graph contains statements.
Something infinitely better is needed here. 

The next section talks about the nodes and arcs of an RDF graph.  However,
an RDF graph contains either triples or statements, neither of which are
known to have nodes or arcs.  This section of the document also talks about
the abstract syntax for RDF, which deserves considerable explanation here,
but is not even linked to the appropriate section of the document. 

The datatype section is explicitly tagged as being normative yet it does
not specify which XML Schema datatypes are unsuitable for use with RDF,
merely mentioning one that is unsuitable.  Similarly, the section mentions
that XML Schema Datatypes provides an extensibility framework without
specifying how such datatypes can be referenced and there are known
problems here.   (This is particularly frustrating from my view as I just
went through this exercise with respect to OWL.) 

The section on literals makes the claim that anything that can be
represented by a literal can be represented by a URI reference.  This claim
deserves some support, and support based on the RDF model theory. 

The RDF model theory does not make recommendations.  Instead, it states
what RDF means in a formal sense.  This is not a recommendation, even if
one considers W3C standards as recommendations. 

A two-place predicate is not a simple fact.  In fact, it is not a fact at
all!  A ground atomic term consisting of a two-place predicate and two
argument terms might be considered as a simple fact as can be represented
in RDF, but not the predicate itself. 

RDF really only has the power to represent the binary
existential-conjunctive fragment of predicate calculus.  The
existential-conjunctive fragment of first-order logic includes non-binary
predicates, which can only be encoded in RDF, and functions, which cannot
even be encoded in RDF.  

The document earlier makes the statement that RDF is supposed to be able to
support assertions about anything.  It now goes on to contradict that
statement, saying that ``[c]ertain URIs are reserved for use by RDF, and
may not be used for any purpose not sanctioned the RDF specifications''.
These cannot both be true.  This section also implicitly makes the claim
that RDF Schema is part of the RDF core, contradicting an earlier claim to
the contrary. 

Section 4: 

What is the ``social meaning'' of RDF?  Does it have any relationship to
how an RDF application should act?  If so, what is this relationship and
how can it be conveyed to an application?  If not, what business does this
have in a document about RDF? 

How does an RDF expression get to be asserted?  What syntax can I use to
assert RDF expressions, or to prevent their assertion?  Can I use this
notion in OWL?  If not, then what good is it?  Without any method given for
asserting an RDF expression or graph, what good is a paragraph that starts
``When an RDF graph is asserted in the Web''?  

Maybe this section on social meaning has a place in some commentary on the
use of RDF, but it certainly doesn't have any place here. 

The idea that RDF graphs contain ``defining information'' that is opaque to
logical reasoners is ludicrous.  An RDF graph is simply a set of RDF
triples.   It is certainly possible that there can be communities that have
intended meanings for these RDF graphs, but these intended meanings are
external to the RDF graph, and, indeed, external to RDF as a whole, and
thus have no place in a normative part of a document about RDF. 

What social conventions surround the use of RDF?  Even if there were some,
why should they make their way into a normative section of an RDF document?
The idea that some owner of a URI reference can control the use of that URI
reference goes counter to the bedrock goal that RDF allows one to say
anything about anything.   The RDF model theory contains no hint that any
of these sorts of restrictions are possible. 

This section further reinforces this point when it says that any document
found by dereferencing a URI reference has no impact on RDF.

The example brings forward these problems.  The document at
http://skunk.example.org/ does not entail anything derogatory about
C:JohnSmith, which is reinforced in the section just above.  This being the
case, there is no reason for any notion related to RDF to bring this
forward. 

If, however, the opposite was the case then there would be no way for any
organization to deploy any RDF-based application.   Such applications would
not be able to understand the social meaning of the RDF they created or
manipulated, and thus could easily create documents holding the
organization liable for just about any imaginable consequence.  In this
case I would have no choice but to tell Lucent Technologies not to deploy
any RDF applications.   

Section 6: 

Just what is an RDF graph?  Earlier it was the Graph Data Model and now it
is the RDF abstract syntax.  I really do expect a much higher level of
internal consistency here.  The definition of RDF triple is not much better
here than before. 

Two graphs are RDF equal iff they are the same.  It would be much better to
call the relationship defined here equivalence, or, even better,
isomorphism. 

The treatment of typed literals here does not match that given in the RDF
model theory.  In particular, there is no provision for the special
treatment of rfd:XMLLiteral there. 

 
RDF/XML Syntax Specification (Revised) Editor's version of W3C Working
Draft XX Month YYYY

Section 2: 

It would be better to state up front that this section is non-normative,
instead of making it subordinate to sections 6 and 7.  In particular, what
happens if section 6 and 7 are silent on some point?  Does this make this
section normative? 

Section 5: 

What does it mean for a namespace to contain a set of names?  How is this
regulated in RDF?  Can the owner of any namespace close off the namespace?
How can this be done in RDF?  Without answers to these questions, saying
that the RDF namespace contains only a certain set of names doesn't make
sense. 

The container property names are not of the form _n where n is a positive
integer, they are of the form _n where n is a  base-10 numeral without
leading zeros that represents a positive integer. 

The statement that other names from the RDF namespace can be used goes
against the idea of a closed RDF namespace and also against certain
comments from the RDF Core WG.  However, it appears to be much closer to
historical truth than these other statements.  

The method for ensuring that there are no clashes between generated blank
node identifiers and blank node identifiers made from rdf:nodeID attribute
values requires a complete pass over the document before any blank node
identifier can be generated.  This is the case because these two sets use
the same set of identifiers and any element of this set can be made from an
rdf:nodeID attribute value.  This problem has been pointed out before but
has not yet been fixed.  The only change has been to add a resolution
method to this section that is not actually allowable from the grammar
rules in Section 7. 

Section 6: 

Referring to the next version of a working draft in a version that is
supposed to be a last call candidate is not appropriate.  If this becomes a
last call working draft then it would be a reason to delay further progress
along the recommendation track. 

Section 7: 

Basing the grammar on an event model makes it more complex that would be
the case if it was based on a tree model such as the Xquery data model. 

The grammar here does not forbid unused terms from the rdf: or rdfs:
namespaces. 

The grammar here explicitly states that the subject of a nodeElement is
formed from the attribute value of any rdf:nodeID attribute in the same way
that the subject is formed from a generated blank node id.  This does not
allow for the trick of using a prefix on the subject in these cases so as
to prevent clashes with generated blank node ids. 

Section 8: 

This section explicitly admits that RDF graphs can use any URI from the rdf
and rdfs namespaces. 

The last sentence of the section is wrong, and, moreover, contradicts the
rest of the section. 

Appendix A: 

The comment about not being able to forbid things starting with _ is
misleading.  The problem is that it is not possible to forbid things of the
form _n where n is a decimal numeral without leading zeros that represents
a positive integer.  The Schema here is incomplete in other ways, including
allowing multiple rdf:ID with the same value. 

 

RDF Vocabulary Description Language 1.0: RDF Schema
@@Not-a-W3C Working Draft 21 December 2003 [sic]

Section 1: 

Is this a normative document or not?  Saying that the semantics document is
more-authoritative is not nearly as helpful as saying that this document is
non-normative.  Also, it leaves unspecified which document is
more-authoritative when this document conflicts with, for example, the
Concepts document. 

RDF Schema is not described in terms of RDF.  This error, which has been
made in several other places, must be ruthlessly eradicated.  Instead, RDF
Schema is a semantic extension to RDF.  

This document again makes the claim that RDF ``allows anyone to extend the
description of existing resources, one of the architectural principles of
the Web''.  Again, would that this were so.  There are many statements in
the RDF documents and being currently made in the RDF Core WG that
contradict this claim. 

RDF Schema is not a set of conventions for using RDF.  It is a full-fledged
semantic extension of RDF, just as is OWL.  It is thus very different from,
for example, the Dublin Core vocabulary.  RDF Schema consists of far more
than a ``collection of RDF resources''. 

Section 2: 

Property is a technical term in RDF and should not be used for other
purposes. 

What is ``common set theory''?  It would be much better to be more precise
here. 

Is RDFS part of the RDF Core?  The Concepts document claims otherwise.
What does it mean that the core RDF specifications define a class?  What
does it mean for a thing to be described by RDF? 

Section 3: 

The RDF semantic does not support the inference that properties with no
rdfs:range or no rdfs:domain have a range or domain of rdfs:Resource.  In
any case, this would be a non-monotonic inference as stated. 

It is misleading to impute any semantics to rdfs:label, rdfs:comment, etc.
It would be much better to state that these properties have no meaning in
RDFS, but are conventionally used for particular purposes.  It is
more-than-misleading to state that such properties clarify the meaning of
RDF classes and properties. 

It would be amusing to find out what users would think of a resource whose
rdfs:comment was "1"^^xsd:57. 

Section [unnumbered]: 

It is more than misleading to say that RDF Schema does not specify how
domains and ranges are to be used.  The RDF semantic states precisely how
domains and ranges are to be used.  Applications, of course, are free to do
other things with domain and range information, and these other things may
even be reasonable extensions of RDF, but any allusion to such activities
needs to have a very strong disclaimer attached to it. 

Section 5: 

RDF containers need much a more careful exposition than given to them here.
Their status is very unusual and their description needs to be more
circumspect.  For example, there is no way that RDF Alternative containers
can only be used for the purposes stated in this document.  It would be
much better to say that such containers are conventionally used for the
purpose.  (It would be even more better to remove them entirely from RDF.) 

It is not the case that rdf:_01 must not be used.  The Semantics document
does not forbid it.  The Concepts document does not forbid it.  The Syntax
document explicitly allows it. 

RDF reification does not allow one to describe a triple.  RDF reification
is nothing more than an uninterpreted collection of resources that are
conventionally used for some weird things that have very little to do with
any form of reification. 

The properties rdfs:seeAlso and rdfs:isDefinedBy are also non-logical.
Their description here should be very careful to not give them any more
status than they actually deserve.  The discussion of rdf:value here is
actually quite good in this regard.  It could serve as a model for the
discussion of the other non-logical properties of RDF. 

Section 6: 

The comments about the non-logical properties in this section are even
worse than their longer descriptions in the previous sections. 


RDF Semantics
W3C Working Draft 12 December 2002

Section 0: 

The two uses of RDF in the first paragraph here are completely
incompatible.  If RDF is to be used as a ``basic foundation for more
advanced assertional languages'' then it must be free of any hint of
meaning that is not sanctioned by its formal basis.  It would be better for
this document to be completely silent about this halo effect that some want
to sanctify. 

It would be much better if this document spoke with one voice on the
meaning of RDF.  This would be best done by an elimination of the Lbase
appendix, but if it is necessary to keep the appendix, then it should not
first be mentioned as one of two versions.  It would be better to first say
that the direct model theory is the meaning of RDF, and to later say that
there is also a non-normative translation into Lbase.  

The last time I checked Lbase was not even a W3C note.  Its status needs to
be upgraded if it is to be referenced in the last-call version of this
document. 

The closure rules are still not correct.  I do not believe that they have
ever matched the current version of RDF.  (They may finally match the model
theory, but the model theory need revision.) This being so, removing the
belief in their correctness is probably appropriate. 

The comment about the meaning of RDF that is not captured in the model
theory is inappropriate.  The meaning of RDF should be the model theory.
In particular, RDF never captured any meaning encoded in URIs nor did it
capture any time-varying aspects of meaning.  The meanings for reification
and containers in the old RDFM&S document are not worth keeping. 

The conditions on RDF semantic extensions do not forbid, and thus they do
allow, extensions to the meaning of the core RDF terms.  This is the only
reasonable way to proceed, but there have been comments that indicate
something to the contrary from the RDF Core WG. 

The mapping from RDF graphs to pictures deserves to be elsewhere, probably
in the Primer.  (If you have a Primer that is supposed to provide
background introductory material, this is a very fine place for it to be
used.) 

Section 1: 

The discussion that indicates that RDF does not handle dereferencing
URIrefs or temporal aspects in this section is much better than the one in
the introduction. 

Section 3: 

Using the term ``reserved vocabulary'' invokes the wrong sort of
connections, as the ``reserved vocabulary'' is not reserved in the sense
used in programming languages.  Instead the ``reserved vocabulary'' is just
a collection of URI references that are given some semantic constraints. 

This section is missing the constraint that IL is insensitive to language
tags for all datatypes except for rdf:XMLLiteral. 

It seems very strange that RDF, an otherwise extremely simple language,
should need all the complexity of XML canonicalization. 

Gracing RDF reification and alternatives with ``reasonably clear informally
intended conventional meanings'' is rather more than generous.  Why not
just say ``informally intended conventional meanings'' without given them
more clarity than can be inferred from all the heat they have generated?
It might even be better to just say ``informal conventional uses'',
sidestepping any mention of informal meanings. 

Why is it necessary to state that semantic extensions can extend the
meaning of the reification vocabulary?  Semantic extensions can extend the
meaning of any URI reference.  The section on RDF reification could be made
much shorter, even without removing the caveats about non-entailments,
simply by removing the irrelevant pieces about a particular informal use of
RDF reification. 

There are several other places where it is stated that semantic extensions
MAY extend the meaning of particular URI references.  None of these are
providing any useful technical information, nor are any of them providing
much in the way of useful informal information. 

The conditions on IL are missing the case of a language-tagged typed
literal. 

Section 4: 

The closure conditions for RDF are incomplete with respect to typed
literals.  In particular it is a consequence of the normative sections of
the RDF Concepts document that 
	<ex:a> <ex:r> "1"@en-us^^xsd:integer .
entails
	<ex:a> <ex:r> "1"@fr^^xsd:integer .

I have not completely analyzed the various closure conditions for other
problems. 

Appendix A: 

The translation to Lbase does not handle typed literals with language
tags. 

Several problems with the Lbase translation have been reported to Pat
Hayes, including a problem with container properties. 


RDF Test Cases
W3C Working Draft 18 December 2002

 

The test cases RDF encoding depends on an external-to-RDF correlation
between URI references and documents.  It would be much better to create
resources for these documents, with a property whose (literal) value is the
URI of the document. 

I have not checked all the test cases for correctness.

Received on Friday, 27 December 2002 12:46:28 UTC