Re: [topicmaps-comment] multilingual thesaurus - language,scope ,and topic naming constraint

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Thomas B. Passin
| 
| Suppose I have a web site (or it could be a processsor that would do
| something further with the information).  I want to link to some
| information in your topic map.  Perhaps I want to get information on
| how to cook a goose, let us say. I don't want to view a
| representation of the information, I want to do some more topic map
| processing on my system, connecting the new information to
| information on geese that I already have. How can I do this?

Right. I see the use case.

I think that we should *not* fall for the temptation to put features
like this, useful though they are, into the interchange syntax. The
interchange syntax should be just that, and not contain this kind of
advanced feature.

I think what is needed is a feature in topic map engines that would
let you perform a query (or a set of queries) and then extract the
retrieved topics with the part of the topic map needed to make sense
of those topics. (This would presumably include base names,
occurrences, associations of some identified types (all of this
possibly filtered by scope), plus the typing and scoping topics used
for the above.)

To me this sounds like something one should be able to build on top of
TMQL, and it sounds like the perfect use case for a topic map web
service. So you could publish your cooking TM as a web service from
which recipes and sets of recipes could be retrieved.

Putting this stuff into the interchange syntax sounds very difficult,
and would also make the interchange syntax very much harder to
implement. The major downside of that is that it makes it a lot harder
for people to write new topic map implementations, as they'll have
much more to implement before they can claim XTM x.y conformance.
 
| 1) I may reference a topic in your map by its uri, but I can't do
| much with that unless I can also reference all the other topics and
| associations in your map the that given topic links to. 

Very true (though you probably don't need all of them). This is why
<topicRef>s to topics external to the topic map are considered to
effectively import the entire external topic map.

| I also have to be able to retrieve them if necessary.  We don't have
| a well-defined way to allow that.  Also, your URIs may change if you
| merge other maps, so my links, if I could establish them, may not
| continue to work.  So I cannot be sure I can update my information
| from you.

I'm not sure this has anything to do with merging. If you publish two
topic maps (a.xtm and b.xtm), why would you want to merge them and
republish them as c.xtm? And, if you do that and remove a.xtm and
b.xtm, all links to topics in a.xtm and b.xtm are going to break,
regardless of whether the IDs change or not.

In any case, by far and away the best way to refer to a topic is by
subject indicator. If you can do that you should. It is only if you
can't that you should start considering the alternatives.
 
| 2) I do not want to import your whole 100 MB map to get information
| just about the cooking of geese, which may only amount to 30 KB,
| say.

Agreed. This is why a remote web service is better than a remote XTM
file. 

| [3) I extract part of your map with a topic map query language. ]
| [...] This is probably the intended way of doing the task, but I'm
| concerned that any such query would not return enough context
| information to make the topics useful for me - that is, to merge
| into my map.  For example, a query might return an association of a
| goose topic with cooking information, but not about what classes the
| "goose" topic and association topic are.  If we have removed the
| names from being children of the topics, as in PMTM4, we may not
| even get the name of the "goose" topic unless we craft a more
| complex query.

I agree completely. If we want to support this kind of scenario, and I
think we do, we need to define a solution that solves this problem. I
tried to outline one above.
 
| You may argue that I should examine the query results and query
| again for any more information I need, but that could easily become
| a resource and time-intensive recursive activity both for me and for
| your server.

Yeah, I don't think this is very good. It may require a lot of queries
before you reach your goal, and I think we can probably come up with
an algorithm that will yield generally-usable results.
 
| [4) I extract a relevant fragment of your map]
| [...] This would be where an xinclude-like ability would come in.
| It's not necessarily the same as an ordinary query, because it would
| include as much context as necessary for the recipient to make
| proper use of the returned information.

Well, how could you do this with XInclude? It seems to me that it
would be very very difficult to get the necessary information into the
XInclude element, for one thing, and that having done that you would
still have achieved nothing more than to create a syntax for
specifying what it is you want, which is precisely what TMQL is
supposed to do. The architectural issue is still left unanswered.
 
| I welcome anything which can show me how this kind of operation will
| not in fact incur serious difficulties of the kind I sketched out
| above.

Your analysis of the problem matches my own very closely.

| Note that none of this applies to the case where a person looks at
| some results in, say, html format, such as in the Ontopia demo
| system.  It applies, rather, to the case where I want to do
| something further in the way of topic map processing.

Absolutely!

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >