[topicmapmail] Web Services

[Thomas B. Passin]

Thomas Schwotzer wrote:

> Other application classes don't need such a fine grained access
> and don't need transactions. Some applications might wish to access
> a Topic Map like a Web Site. They ask for some information and get
> a Topic Map fragment in return. SNAPI shall become such an API.
> It is supposed to be a kind of HTTP e.g. for Topic Maps. There are
> no transactions and also no way to access a particular topic.
> XTM fragments can be exchanged. Advantage: Light-weight implementations.
> 

There are two kinds of things to deal with in this arena, I think -

1 - How should you ask for some relevant part of a topic map (so as to 
avoid getting the whole thing when it is not needed)?

2 - What is a "relevant" part of a topic map, anyway?  How do you know 
where to stop?

I think the most promising approach for 2) - really the only one I know 
about - is the "Concise Bounded Description" Proposed (for RDF) by 
Patrick Stickler - see

    http://sw.nokia.com/uriqa/URIQA.html

This is actually easier to do in topic maps than in RDF because we don't 
have to do extra work to find and chase down all the anonymous nodes.

Basically, the CBD gives you all topics that are directly related to a 
given topic.  Thus the results have a depth of just one.  To follow up 
on any of them you ask for its CBD.  In RDF, it would be all triples in 
which the given node is a subject, and all triples for all bnodes 
connected to that node (continuing, if I have it right, until you have 
exhausted each chain of bnodes),

I tried this out experimentally with my topic map engine.  It was pretty 
easy and seems to work well.

Cheers,

Tom P