RE: comments on Guidelines for RDF/Topic Maps Interoperability

* Peter F. Patel-Schneider
| Comments on Guidelines for RDF/Topic Maps Interoperability
| 	    W3C Editor's Draft 10 February 2006

Thank you, Peter, for your quick response and for many useful comments.

The document somewhat reflects the author's lack of deep familiarity
with RDF/OWL and the fact that it has not yet been reviewed by the whole
RDFTM task force. Your comments will go a long way to helping us improve

I would like to address some of your issues at once. Others will have
to wait until the editors have had a chance to discuss them, or until
I've heard back from you.

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

The word "proxy" has been used extensively in the Topic Maps community
to denote a symbol used within a data structure to represent something
that is outside that structure. Having now checked the Topic Maps Data
Model [1], I see that "proxy" is not used there at all -- only "symbol".
Perhaps we should adopt the same term in our document.

We certainly *need* a term, because the distinction between topic and
subject is quite fundamental.

| 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 ( for a very
| full treatment of this important issue.

It was not our intention to suggest that RDF is unclear on the distinction
between resources and identifiers, but rather on the distinction between
the subject of discourse (say, "love"), and the symbol used to represent
it. In our experience, the term "resource" tends to be used for both. We
would appreciate hearing from others whether this is the case or not.

In what follows, I assume that you are using "resource" more rigorously,
to mean only "the thing denoted."

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

According to your strict definition of "resource", this is, of course,
correct -- just as subjects (in the Topic Maps sense) exist independently
of whether they are represented by a topic in some topic map.

However, our usage in this paragraph is, as made clear in the document,
"resource in the sense of symbol", (or "RDF-node-that-is-not-a-literal").

| It is also possible to "invent" a statement for any resource in RDF*S*,
| namely being an instance of rdfs:Resource.

That's a good point. In that case, we don't need the first sentence quoted

| Similarly, properties exist in RDF independent of being the denotation
| of an URIref.

Once again you are using "property" in the sense of "thing denoted" (what
Topic Maps would call the relationship), rather than the symbol used to
represent it (what TMs would call the association).

In that case, I agree with you absolutely. However, once again, it is my
impression that "property" tends to be used for both in the RDF community.

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

All this makes sense given your strict usage of the term "resource". I
suspect your (very reasonable) response would be to suggest that we also
adhere to the strict usage... But that leaves us without terminology to
talk about the symbol when describing translations between Topic Maps and

It seems that the problem stems from the fact that Topic Maps has three
concepts in this area (things/subjects, symbols/topics, and identifiers)
where RDF (possibly) only has two (things/resources, symbols/identifiers).

I'm not quite sure how to address this.

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

The "ambiguity" resides in not knowing whether the URIref identifies the
thing (usually a document) that it resolves to, or something described,
indicated, or otherwise intimated by that thing: in other words, the whole
httpRange-14 issue. Perhaps we should use another word than "ambiguity"?
(Uncertainty? Vagueness? Ambivalence?)

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

This is an interesting comment. It raises the question whether the Guidelines
should reference OWL in any way. We have taken the position that properties
defined by OWL are legitimate ways of providing translation guidance.

We would be interested in hearing whether the WG agrees with this position.

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

Please explain this. What meaning *does* Example 16 have? What apparent meaning
does it *not* have?

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

I think you may have misconstrued Topic Maps on this point. Consider the
following example taken from section 3.6.1 and slightly extended:

  1)  bio:born-in( puccini : person, lucca : place )
  2)  [puccini : composer]
  3)  [lucca : city]

Based on these three statements, all we know about Puccini is that he
belongs to the class "composer" and plays the role of "person" in a
"born in" relationship with Lucca. Puccini is *not* a member of the class

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

In Topic Maps, it certainly could be symmetric:

  loves( steve : lover, sylvia : lover)

Why could it not be in RDF?

(We might need to go a couple more rounds on this.)

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

Noted. What we do about this depends on the WG's view on the role of OWL.

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

I await your answer to 7/ (above) before commenting on this. I am not
familiar with "the problems of RDF reification" and I don't know whether
this problem is generally recognized in the Semantic Web community.

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

Our goal is that the results of translation should be as natural as
possible. Given that scope is routinely used in Topic Maps to handle
natural language, we have no choice in this -- unless there are really
substantive arguments against it.

Please explain why the treatment is 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.

We appreciate your review and fully intend to fix any problems that
turn up. This is just the first Editor's Draft, so we don't expect it
to be anywhere near ready for upgrading yet :-)

Best regards,



Steve Pepper, Ontopian

Those cartoons: The issue is racism

Received on Sunday, 12 February 2006 11:59:44 UTC