[sc34wg3] TR: comment - RDFTM: Survey of Interoperability Proposals

[Lars Marius Garshol]

* Peter F. Patel-Schneider
| 
| Well, aside from the fact that there is little about meaning in the
| TMDM, the TMDM is not a formal document.  It attempts to specify
| what is going on in English, not in any formal specification
| language, and like all such attempts that I have seen, is full of
| problems.

I think whether one agrees with what you wrote or not depends a lot on
the definitions of "formal" and "meaning" that you use, and also what
your expectations for the document are. If you expect it to be a piece
of maths you are definitely going to be disappointed. It is not, and
it was never meant to be.
 
| For starters the definition of merging is broken.  The definition of
| when merging must happen talks about "change", but there is no
| notion of a change to a topic map in the rest of the document.

It's true that merging has been given a special status as the only
form of change that is done to a topic map. We could have moved it out
to the XTM syntax specification and had all the changes performed by
deserialization of XTM, but there were some arguments against this:

 1) The merging is generally considered to be part of the topic map
    model itself

 2) Other specifications (third-party syntax specifications, TMQL,
    TMAPI, etc) will need to use the same definitions of merging

I admit that from a formal perspective merging does have an odd status
in the model, but this seemed to us to be a part of the beast being
modelled, and also the most practical editorial solution.

| When, then, is merging to be performed?  Perhaps only in response to
| other merges?

The document says when it requires merges to be performed. (In other
words: when TMDM says it must be performed.)

| Consider also the following wording concerning merging:
| 
| 	It is an error for two different information items to have string
| 	that are equal in their [source locators] properties, unless they
| 	are topic items. If they are topic items they must be merged
| 	according to the procedure in 6.2.
| 
| How is this to be interpreted?   

I'm not sure what the problem is here. This is a rule of the kind that
is perfectly normal to find in IT specifications. The XML
recommendation has things like this, the URI RFC does, the HTTP RFC
does, the XPath and XSLT specifications do, etc etc

So as a piece of IT engineering this is perfectly normal. I accept
that it probably horrifies mathematicians, but then the document was
never meant for them in the first place. It was meant for software
engineers who have to implement this, for the simple reason that
implementations of topic maps were considered more important than
theories of topic maps. (Note that I'm not saying theories are not
useful, only that they are less useful, relatively speaking.)

We are working on a model called \Tau (into which TMDM will be mapped)
which is going to be a mathematical model, so in the future we hope to
be able to satisfy both camps in a reasonably consistent fashion.
 
| The definition of a valid topic map appears to require knowledge of
| arbitrary external information.  For example
| 
| 	The process of merging ensures that whenever two topics are known
| 	to represent the same subject they are merged. It may well be,
| 	however, that two topics may represent the same subject without
| 	this being detectable by the rules of this part of ISO/IEC
| 	13250. Merging beyond the minimal merging required by the rules of
| 	Clause 6 is freely allowed. Most commonly this will be done by
| 	inferring the subject of the topics from their characteristics.
| 
| What is the status of the extra merging?  Is it part of topic maps?
| If so, then how is it possible to determine when a topic map is
| valid?

Here I think you are right that the text could be clearer. 

What it tries to say is simply that we *know* these merging rules
won't actually merge topics in all the cases where the topics should
be merged, precisely because the necessary external information is not
available to the processor. Therefore, users are freely allowed to do
additional merging (just as they are allowed to create, edit, and
delete topic maps any way they please).

So the extra merging is *not* part of the standard, and I think the
text here fails to make that as clear as it should. That's actually
very useful feedback, so I'll see if we can fix this by turning the
text into a NOTE and tightening it up a bit.
 
| Similar issues occur elsewhere.  In each case it appears to be
| impossible to determine what constitutes a valid topic map.

I'd very much appreciate it if you could tell us where else you've
found issues like this, since that should help us improve the
document.

| As well the merging operations do not remove the equal information
| items from the topic map.  This leads to a non-terminating process.

What do you mean? The merging operations always create a new item C,
and then say that A and B are to be replaced with C wherever they
occur. Given this I don't see how we could have this problem. Did you
miss something, or did I?
 
| Consider as well the situation with null.  It is a type?  (It seems
| so because it is in the list of types.)  Can it have values?  (This
| is unstated.)  Can it serve as the value of an information item
| property?  Apparently not, because only values of the types are
| allowed, not the types themselves.

It's explicitly stated further down that "null" can be the value of
some properties (in the definitions of specific properties). I'd
interpret this as meaning that "null" is the only possible value for
the unnamed "null type". I guess you are right that naming the "null"
type may be worth doing. We would only use that name right here,
however, and never to refer to the type (because we have no need to
talk about the type, and so never do), so it would mainly be a
cosmetic change.

I've made a note of this, and we'll look into it to see if we really
do want to change this.


However, from my perspective what you have done now is to identify
some parts of the document that aren't as precise as they could be,
but which are unlikely to cause experienced implementors much trouble.
I doubt that is how it seems to you, however. I guess the question is:
how relevant are the problems you perceive with TMDM to topic maps/RDF
interoperability? 

And, secondarily from a W3C perspective: are the problems you perceive
with TMDM real problems for the topic map community?

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >