[topicmapmail] Web Services

[Thomas Schwotzer]

> Lars Garshol:
> 
>>Not sure exactly what you are asking here. Could you expand?
> 
> 
> Uhm. 
> 
> Well I guess the question is whether an analogy between database server
> and 'topic map server' would hold in real world development.
> 
> That is, by analogy to the following two step process.. 
> 
> Database query and return of result set..
> 
>  [Application] --> (SQL) --> [JDBC] --> [Database]
>  [Application] <-- (Java Result Set) <-- [JDBC] <-- [Database]
> 
> Could we instead think of a two step  'Topic Map' process.. 
> 
> [Application] --> (TMQL) --> [WebService] --> [TM Server]
> [Application] <-- (XML Results) <-- [WebService] <-- [TM Server]
> 
> (and we would also have similar analogies to data insert, data update
> etc...)
> 
> The question, then, is this. Is this a good way of setting up your topic
> map server when actually doing development, or do people using topic
> maps in practice see much more closely coupled development being
> necessary to do the work, that is opening and manipulating TM objects
> and then persisting them. I guess more in the vein of the TM4J API style
> approach.

I think, different API are required for different purposes.
If you want manipulate TM objects (from remote), an API like
TMAPI, TM4J API or of course Ontopias API should be used.
All these APIs are session oriented. I database speech: You need
transactions. But handling remote transaction can be time consuming
and error-prone.

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.

> Please forgive me for talking in a vacuum. I am trying to get an idea of
> how this all might work before I actually build the thing. It may seem
> 'backwards' but if I have no idea at all how things might work
> architecture wize in practice its kinda hard to plan out the project..
> 
> I would be very keen to hear any comments on whether I am just way off
> on planet unreality here, or if the (below) are real issues from anybody
> with experience building 'real world' TM applications.  Anyway where I
> can see this analogy breaking down is, well in two ways...
> 
> 1 - DataSets (aka Java result sets) versus "XML Results"
> 
> I guess the easiest way to format results would be in the form of an
> "XML Topic Map Fragment". Now, please tell me if I'm wrong, but I get
> the idea that XML Topic Map Fragments don't really lend themselves
> especially easily to presentation in web pages via XSLT. Perhaps one
> needs to first transform standard XTM into some sort of generic
> 'simpler' XML representation more appropriate for XSLT presentation. Has
> anyone experience with XSLT & XTM to report on?

In two month our Web Site (ivs.tu-berlin.de) will be generated
directly from XTM. We already have a prototyp in the lab. We use
XSL but not only one monolithic file. There is one XSL file for each
topic type. There is also a topic map which maps each topic type
to a XSL file.

This makes it - hopefully ;-) - maintainable. We don't have
experiences with runtime behaviour etc. yet.

My favourite will be a new feature: Every page has a link to get the
"XTM source". This "source" is in other words the XTM fragment which
was visualized by the HTML page. This fragment could now be merged
into another Topic Map.

> 2 - XML Results versus Instantiated Results.
> 
> It could be that this whole idea of working in XML Result fragments is
> going to be impossible to use, even just for presentation, let along for
> update. That is, without the 'type-of' associations and all that sort of
> background framework represented in some way (perhaps as a class
> hierachy?) maybe the XML data is not 'meaningful' enough to be easily
> used. Rather one needs, perhaps, to first read in the XML and
> 'instantiate' it into a framework of objects and the like. If that is
> the case, then uhm I gotta have a representation of Topics and
> Associations and such in C# anyway, and I'm kinda wondering if I have
> saved myself any effort or not. Maybe I have ?
> 
> --
> 
> All just random ramblings really at this point, hoping that someone can
> see through the murk of my confusion and offer me advice as to how best
> to think of this in terms of architectures for building real
> applications that display and update a fairly large corpus of TM data.
>  
> Miles
> 
> 
> _______________________________________________
> topicmapmail mailing list
> topicmapmail@infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail
> 
> 

-- 
Thomas Schwotzer
University of Technology Berlin
Intelligent Networks and Management of Distributed Systems
http://ivs.tu-berlin.de/Schwotzer
fon: +49-30-314-79834 fax: +49-30-314-24573