[xtm-wg] Topic Map Queries

["Wrightson, Ann" <Ann.Wrightson@sweetandmaxwell.co.uk>]

-------------------------- eGroups Sponsor -------------------------~-~>
Great savings and lots more -- beMANY!
http://click.egroups.com/1/8034/4/_/337252/_/968869586/
---------------------------------------------------------------------_->

I think this may be of interest to this list wrt XTM design -
comments/questions welcome, of course.

Topic Map "Queries"

DRAFT position paper
Ann M Wrightson
September 00

Since many language bindings and interfaces to data repositories use query
languages to codify means of access to the information contained, it has
become natural to pose the question "how will I, in practice, retrieve
information from this repository" as "what's the query language for this
repository". However, Topic Maps are potentially quite different from
structured repositories because the Topic Map concept has deliberately
forgone the tidy regularities of structure (eg tuples, hierarchies) which
make searching and retrieval in other technologies (eg relational database,
SGML Grove) formally well-behaved and so subject to the regularities of a
query language.
(Note: I haven't forgotten that a Topic Map in its entirety is an SGML
document, hence a grove, hence searchable-as-such - but I want an approach
which can respect what a particular topic map is intending to say, not just
its formal structure and literal tokens.)

What's wrong with SQL-like Topic Map query approaches (eg  Rafal Ksiezyk's
approach in his Paris paper)? Not a lot - if you consider topic maps to be a
way of organizing an information set which already "tidy", eg of known
extent, and with a well-defined type structure over it. However, the intent
& probable reality of many "interesting" TM goes beyond this.  Eg RK uses
predicate calculus, and desires transitivity in topic maps - the first is an
unrealistic assumption (and one which has caused problems with respect to
"classical" AI/KBS too), and the second would ruin topic maps as carriers of
non-monotonic, fuzzy-real-world information. 

However, you do need ways of effectively finding and retrieving the
information which is reached by your topic map - otherwise it's useless.

The closest thing-which-we-know-well to an arbitrary large complex Topic Map
is IMHO the WWW. (In principle, you could construct a topic map from the
WWW-as-it-potentially-appears-on-my-PC-at-this-time.)
As we all know, you can't search and retrieve effectively on "the WWW" as
such. What does work pretty well, is to construct "standoff" searchable
structures for particular purposes, which are eg constructed using the Topic
Map-like structure of the base data, by software agents which have rules
enabling them to slot whatever they find into whatever indexing or
navigation structure they are being used to construct.
My proposal:
In order to keep the full power of Topic Maps, there must not be a single
"topic map query language". Instead, it will be a normal part of the design
of a large Topic Map application, that the search-and-retrieval metaphors
and mechanisms appropriate to that application are designed alongside the
Topic Map structuring and construction/discovery rules (and sometimes the
content structures too) for the constituent domain(s). Of course, it will be
helpful to have a suite of "usual suspects" for these metaphors and
mechanisms - and the pilot implementations we've seen in various conference
presentations recently provide a good selection as a starting point.
Methods and techniques to develop - what's needed?
The XTM usecases survey revealed that the majority of examples in
participants' minds were to do with enabling navigation and
cross-referencing to related material within content; others were to do with
general topical organization and indexing; and although this aspect was
poorly represented in the survey, there has also been some strong interest
in supporting reasoning/inference.
All three of these have existing traditions (theory, examples and proven
techniques) of enabling people using systems built that way to find
information. They also have related modes of analysis and design - eg for
topical organization, you can start by building an ontology; for navigation,
you can start by doing a user task analysis; for reasoning, you can start by
building a theory of your domain. 
Any of these can then be used for designing two things: a suitable structure
(or more likely, construction and maintenance rules) for the Topic Map, and
the required searchable/inferential/index structure (which just to make
things confusing, could be itself a topic map, even one merged with the
first).

AMW 13/9/00

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com