From: Kal A. <ka...@te...> - 2004-02-02 21:26:12
|
On Mon, 2004-02-02 at 21:02, Stefan Lischke wrote: > Hi there, > > I get the Feature Request eMail from Kal, in which he proposed to allow > XML Data in the resourceData Element. > As far as i know this will also be allowed in the next XTM standard. > > I have some discussion points for you: > XTM is metadata for some real data, maybe in an occurrence or directly > in resourceData. So it is not enough for a TopicMap engine to just > handle/index/query the Metadata. I think it should also be possible to > query the "real Data" inside the resourceData Element. > Since we are working with XML and we allow XML-Tags in resourceData, > than querys can be done via XPath or XQuery. > You all are pinned to the relational or OO Backend for a TopicMap > Engine, so querying by XPath or doing XQuery on Gigabytes of TopicMaps > should be very difficult to implement. > That is true, but the topic maps model is not the same as the XTM syntax - when you have to consider merging and the topic references (which create a graph), then it gets quite a lot more difficult - especially when you can have cases where the merging of two topics could then cause further merging because they change how names are scoped. > I want to open discussion about a native XML Backend for a TopicMap > engine, like i did with XTM4XMLDB (also @sf.net). I know my > implementation of TMAPI with a native XML:DB Backend is really a quick > hack, but i think it is worth to think about. > Currently with eXist (also @sf.net) as Backend, i don't have to create > indexes for all the TopicMapFields like basename and so on, cause the > XMLDB is indexing the whole DOM. If you want something quick out of > Gigabytes of TopicMaps XPath is doing the work in milliseconds. You can > query for something inside xtm namespace or just inside the resourceData > without any problems. > There was a DOM backend that was started a while ago but it didn't get completed. I had always thought that this DOM backend could possibly be a good way to use a native XML database. My thought was that you could annotate the XTM syntax with additional attributes (maybe in a different namespace) to handle the results of merging and make it easier to then query the XML structure with XPath to do TM4J API calls. There is another alternative, which would be to use TM4J's JDBC/Ozone implementation in paralell with an XML DB implementation, with the XML DB implementation providing an Index view. This would be a parallel to the FullTextIndex that Harald has just committed to CVS. So it would only handle queries against the content of resourceData elements for example. That way you could represent the topic map as data in JDBC/Ozone backend + a number of micro-documents in a native XML database. Just a thought :) Cheers, Kal -- Kal Ahmed <ka...@te...> techquila |