Re: comments on Guidelines for RDF/Topic Maps Interoperability

From: "Steve Pepper" <pepper@ontopia.net>
Subject: RE: comments on Guidelines for RDF/Topic Maps Interoperability
Date: Sun, 12 Feb 2006 12:59:32 +0100

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

Hmm.  Here is another problem.  RDF doesn't really have "data structures" - not
even RDF graphs fill this bill.  RDF instead is a logic (a somethat unusual
logic, but a logic nonetheless).  You really need to use the terminology of
logic when talking about RDF, not the terminology of programming languages.

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

Well, maybe, but you really, really, really need to be crystal clear on
whatever distinction you are trying to make.

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

But of course!


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

It may be the case that people who use RDF are sloppy.  It may also be the case
that older documents about RDF were also sloppy.  However, I believe that the
current RDF recommendation documents are very clear on the distinction.

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

Yes, I am using "resource" rigourously.  But, however, a resource is not to be
considered as simply "the thing denoted".  Resources in RDF exist independently
of whether or not they are "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").

DON'T DO THIS.   Repeat after me, "DON'T DO THIS".  If you are going to use the
term "resource", use it in the way that it is used in RDF.   No matter how you
qualify your use of the term "resource", when talking about RDF "resource"
means something in the formal universe of discourse.

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

Yes, this is the RDF meaning of the term.  Therefore, I use it this way, and so
should you! 

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

I am not responsible for sloppy terminology by users of RDF.  You should be
using "property" in its proper fashion.

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

Let me be blunt here.  If you don't use "resource", "property", and other
technical RDF terms correctly, your document will be totally worthless!

> But that leaves us without terminology to
> talk about the symbol when describing translations between Topic Maps and
> RDF.

What is wrong with URIref (actually IRI reference)?  This is what RDF symbols are!

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

Well that is your problem.

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

I am also unaware of any "uncertainty", "vagueness", or even "ambivalence"
about identifiers in RDF.  Actually, RDF is very clear about the situation.  An
identifier in RDF denotes a resource completely independently of anything
related to whatever document, if any, can be retrieved by using the identifier.

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

If you are using parts of OWL, then you should really be taking into account
all of OWL.  Contrariwise, if you are not taking into account all of OWL, then
you should not be using any part of OWL.

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

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

The RDF translation does *not* imply that there is any domain element with name
"Giacomo Puccini".  

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

Aah, but then you really need to change a lot of the document.  foaf:Person is
a class name.  Using it to signal association placing is going to cause a *lot*
of problems. 

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

Loves is not symmetric!  Because it is not symmetric, treatments that conflate
typing and association arguments are extra-problematic.

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

I suggest that you go through the voluminous deliberations of the RDF Core
working group on this point.

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

Because adding a scope results in changing the mapping.  (Although it may be
that I don't understand TM Scoping adequately here.)

> | 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
> 
> [1] http://www.isotopicmaps.org/sam/sam-model/
> 
> --
> Steve Pepper, Ontopian

peter

Received on Monday, 13 February 2006 14:18:57 UTC