[topicmapmail] Web Services

[Jan Algermissen]

Lars Marius Garshol wrote:
> 
> * Jan Algermissen
> |
> | The idea is that a topic map server can make certain portions of a
> | topic map available, that suit common information needs. Some
> | examples of such portions are
> |
> |   - the 'index' of a topic map, meaning the list of topics with
> |     their occurrences and the titles,abstracts,authors, etc. of the
> |     occurrences
> |
> |   - the 'reverse index', meaning the list of information resources
> |     and the subjects they are occurrences of
> |
> |   - the list of all classes
> |
> |   - the list of all roles
> |
> |   - the list of all assertion types
> |
> |   - several forms of hierarchical structures, such as a
> |     superclass-subclass tree or a spatial-containment tree
> |
> |   - hitlists based on certain properties/situations of topics
> |
> | many of these are present in the available topic map browsing
> | softwares in one form or another.
> 
> Hmmm. This makes sense to me, but couldn't you express all of those
> conditions as queries? 

Maybe you can....I couldn't, too dumb. My problem is not related to
'selecting' the list of topics that go into the result set (is it a set?)
but in specifying what information about them is to be returned. But I
am not arguing against a QL here. If it is possible, I'll be very happy.

It seems trivial to me to produce tolog queries
> (and the same would probably apply to the other QLs) that express each
> of these portions.
> 
> | The above conceptual portions can also be parameterized in order to
> | retrieve only certain substes (e.g. index from A-C or some tree
> | starting at X and going down n levels)
> 
> That requires a more powerful query language, but you're still within
> the limits of what a QL can be expected to do.
> 
> | This way of accessing topic maps integrates nicely with Web
> | architectire because the conceptual portions can be understood as
> | resources and topic map servers can provide links to them to guide a
> | user or agent (this is known as drill-down and navigation from a
> | REST POV).
> 
> Yep, and I think that's a very sensible approach.
> 
> | Suppose a topic map server provides the xmltools map at
> |
> | http://www.example.org/topicmaps/xmltools
> |
> | then several portions could be accessed as:
> |
> | http://www.example.org/topicmaps/xmltools/index
> | http://www.example.org/topicmaps/xmltools/classes
> | http://www.example.org/topicmaps/xmltools/roles
> 
> Right. So here you have effectively named queries, instead of exposing
> the query interface directly over the web. We will probably create
> something similar for our TM server product. That is, you can created
> named methods that are implemented with queries, and which can be
> rendered as XTM fragments or in some other way that you specify.


Stored procedures....?  See my answer to Murray. But still...if since
SQL is completely declarative I want the same for Topic Maps too ;-)

So, who's defining "Topic Maps Calculus"? ;-)

> 
> | Of course there is more to all this, especially interoperability
> | issues (e.g. the portions have to be commonly known/understood for
> | non-human interactions) but I am still working the details out.
> 
> I like what you've described so far. It seems like there's even more
> work going on in this area than I was aware of, which is very cool.


Yeah, I also had this experience today ;-)


Jan



> Probably there should be a standard for this eventually, but I don't
> think the time has come for an ISO standard for this yet.

> 
> --
> Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
> GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >
> 
> _______________________________________________
> topicmapmail mailing list
> topicmapmail@infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org