W3C home > Mailing lists > Public > public-swbp-wg@w3.org > February 2006

comments on Guidelines for RDF/Topic Maps Interoperability

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Sat, 11 Feb 2006 14:08:20 -0500 (EST)
Message-Id: <20060211.140820.124068712.pfps@research.bell-labs.com>
To: public-swbp-wg@w3.org

Comments on Guidelines for RDF/Topic Maps Interoperability
	    W3C Editor's Draft 10 February 2006

1/ I am unaware of the use of "proxy" in any RDF document or model theory.
Whatever a proxy is, it is very unlikely that an RDF resource is a proxy.

2/ The RDF model theory is *very* clear on the distinction between resources
and identifiers.  Resources are elements of the domain of discourse; URI
references are identifiers and denote resources.  RDF nodes are syntactic
entities and can be either URI references, blank nodes, or literals.  See
Section 1 of the RDF Model Theory (http://www.w3.org/TR/rdf-mt/) for a very
full treatment of this important issue.

3/ The document has a very serious misconception on the nature of RDF resources
in Section 3.1:

	A topic that has no characteristics or identifiers cannot be mapped to
	a resource, since resources only exist in the context of RDF
	statements. It can also not be mapped to a property, since a property
	requires a URIref, which can only come from a subject identifier.

I do not believe that this is the case in RDF.  Resources exist in RDF
independent of whether they impinge on any RDF statement.  It is also possible
to "invent" a statement for any resource in RDF*S*, namely being an instance of
rdfs:Resource.  Similarly, properties exist in RDF independent of being the
denotation of an URIref.

Identifiers in RDF denote resources, but do not belong to these resources.  RDF
resources certainly do not have to "have" (be denoted by) at most one URIref,
so there is no way to talk about "the URIref of [a] resource".  Differential
treatment of URIrefs that (somehow) denote the same resource is not sanctioned
by RDF (or OWL).

4/ I am unaware of any "ambiguity" in RDF as to the status of identifiers.
Identifiers in RDF always denote some domain element.  I worry that the
approach taken in Section 3.3 is unnecessary and non-monotonic.  This worry
appears to be bourne out in the RDF2TM: Identity box.

5/ The built-in OWL URIrefs (like owl:sameAs) only carry special meaning in OWL
- using them in RDF and RDFS does *not* provide any special meaning.

6/ RDF properties *are* resources.  Any treatment of RDF properties would be
*in addition* to their treatment as resources.

7/ RDF reification is *extremely* problematic.  In particular, Example 16 does
not have the meaning that it seems it should have.  (If RDF reification had the
meaning it appears to have in Example 16, then RDF reification could be used to
solve the problem of untyped occurences.)

8/ It appears to me that there is a serious problem with the treatment of
binary associations.  The intuitive meaning of the "typing" information in the
bio:born-in example does *not* identify roles in the bio:born-in relationship,
but instead provides typing information about the two resources.  Conflating
these two important ideas is sure to lead to severe problems.  Consider, for
example, a "loves" association which relates people to other people but is
*not* symmetric.

9/ The section
	A binary relationship that is represented by a single association may
	be represented by two RDF statements whose properties are the inverse
	of each other. ...
again requires use of concepts from OWL which are not present in RDF.  In OWL
the subsequent creation of a "second RDF statement" is unnecessary.

10/ Because of the problems with RDF reification, the treatment of scope is not
going to work.

11/ I am deeply skeptical about using scope to capture language tags.  As well,
the treatment appears to be non-monotonic.


I sum, I see serious problems with the current document.  Fixing the problems
that I mention above is likely to bring to the fore more serious problems.  All
the problems in the document need to be fixed before its status can be
upgraded.
Received on Saturday, 11 February 2006 19:08:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:46 UTC