[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xtm-wg] Dynamic Generation and Serving of Topic Maps
* 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC