Re: [xtm-wg] Dynamic Generation and Serving of Topic Maps

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Lars Marius Garshol
|
| Furthermore, to TMQL, the actual form in which the topic map happens
| to be stored should not matter at all.

* Murray Altheim
| 
| This is only true if you're not interested in an interchange syntax.

Not at all! Interchange means just that: interchange, transport. Any
TMQL implementation will have some sort of internal representation of
topic map constructs. As long as they can create this from the
interchange syntax they support the interchange syntax as far as it
needs to be supported.

| That's what we're doing here. The ISO spec already *describes* topic
| maps. The conceptual modelling group is fleshing out the model that
| is implicit in the ISO spec. We're harmony-checking.

Here we are mostly in agreement.  However, we are not just
harmony-checking, methinks, but also documenting important things that
13250 left unstated.  These things are, in my opinion, very important
for any further syntax discussions and much seems to now be discussed
in terms of syntax that should really be discussed in terms of the
underlying model.
 
* Lars Marius Garshol
|
| Obviously, SQL is not a good fit for XML documents, just as XPath is a
| very bad fit for relational databases. I don't think XPath is a very
| good fit for topic maps either.
 
* Murray Altheim
|
| SQL is not a good fit for XML documents because it was designed for 
| live, in-memory database applications. XPath isn't a good fit for 
| topic maps once they're in the "graph", as Steve says. But going from
| XML document to in-memory representation is what XPath is about.

The reason SQL is not a good fit for XML documents is that the data
models are very very different, which means that the features SQL
provides are not very appropriate for XML. The same applies to XPath
and relational databases. Relational databases just don't have
attributes or namespaces, just as XML documents don't have tables in
the way that SQL expects.

The issue is not at all about whether things are in-memory or not,
because both SQL and XPath assume that they are; as should TMQL.

| The results of XPath queries are aggregated to create TMQL queries.

Of course, it is possible to represent topic maps as XML documents and
then try to query them using XPath expressions. There are two major
problems with these, one of which is very serious while the other is a
total showstopper:

 - as Graham pointed out, XPath is not very suitable for the kinds of
   queries that one would typically want to do with TMQL, nor should
   one expect it to be. 

   Typical TMQL queries will be along the lines of 'find all topics
   that have a born-in association with the same city that they have a
   died-in association with'.

   Try to formulate this using XPath and then test the resulting query
   to see how efficient it is. Most likely performance will be
   absolutely horrid, because XPath was never meant to do this kind of
   thing.

 - topic map engines just plain WILL NOT represent topic maps
   internally as XML documents, for the very simple reason that it
   will be incredibly awkward to do so. 

   This means that in order to apply XPath queries to topic maps
   residing in topic map engines these engines will have to map their
   topic maps into virtual XML documents, perform the XPath queries on
   these virtual documents, and then map the results back to topic
   maps. 

   There is no way that this approach makes sense.

What this means is that a TMQL that is specified using XPath will be
very contorted in its specification because it is specified by bending
something not suitable for the task backwards to do the job anyway.

It also means that the result will only be applicable to topic map
documents that reside outside topic map engines. Topic maps will only
be maintained in this form in toy projects, and why on earth should we
bother to create a TMQL restricted to toy projects?
  
* Lars Marius Garshol
|
| Why should we be? XPath doesn't work very well for relational data
| either. Does that also mean that we're in trouble?
 
* Murray Altheim
|
| If one can't use XLink/XPointer/XPath to obtain the necessary data
| from an XTM document (as an XML document) then we're in trouble.
| Ie., if one can't use common XML tools as a basis upon which to
| build topic map tools, then the market will favour technologies that
| can, like RDF.

What makes you think XPath is useful for RDF? As far as I can tell,
none of the current RDF tools use the XML data model. 

The RDF parsers[1] all provide RDF-specific APIs to the parsed RDF
documents, just as the databases[2] do not store RDF documents as XML
documents, causing the exact same problems that I described for topic
maps.

This article

<URL: http://www.xml.com/pub/2000/10/11/rdf/index.html >

describes the architecture of one RDF framework, and as you can see it
is based on the RDF data model, not the XML one. The query language is
also not based on XPath, nor could it easily be.

--Lars M.

[1] <URL: http://www.garshol.priv.no/download/xmltools/cat_ix.html#SC_RDFParser >
[2] <URL: http://www.garshol.priv.no/download/xmltools/cat_ix.html#SC_XMLDBMS >
    (too thin at the moment, sorry)


-------------------------- eGroups Sponsor -------------------------~-~>
Create your business web site your way now at Bigstep.com.
It's the fast, easy way to get online, to promote your business,
and to sell your products and services. Try Bigstep.com now.
http://click.egroups.com/1/9183/1/_/337252/_/973673596/
---------------------------------------------------------------------_->

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

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