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-Zo64W7twoUFWk0Htik3J/w@xxxxxxxxxxxxxxxx
> http://www.infoloom.com/mailman/listinfo/topicmapmail
--
Jan Algermissen http://www.topicmapping.com
Consultant & Programmer http://www.gooseworks.org
|
