OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [topicmaps-comment] mapping topic maps on a relation database


Lars Marius Garshol wrote:

> * Lars Marius Garshol
> |
> | Basically you would have to create a new DTD (call it XTM') and then
> | transform from XTM to XTM' before storing it. Otherwise performing
> | simple queries like "show me all composer born in Italy" is just
> | plain hell to compute, since you would have to do things like
> | merging, following three different kinds of references etc during
> | the query evaluation.
> 
> * Murray Altheim
> |
> | Unless you always stored already-merged topic maps. 
> 
> That would do away with the merging problem, but following three
> different kinds of references is not much fun either. That's why I
> recommended using a simplified XTM (with no <subjectIndicatorRef> or
> <resourceRef> elements outside <subjectIdentity>). A simplified
> representation like that would be workable.
> 
> The question is also: how are you going to do the processing from XTM
> to XTM'? It seems pretty tricky to me, unless you use a OO API to
> represent your topic map, and if you do you might as well hide all
> that ugly XML stuff behind it. At that point XTM' becomes just another
> storage mechanism, and definitely not the easiest to query.


I've currently got LTM, XTM and several other syntaxes parsing into
a set of Java objects, so yes I guess I have an OO API in effect. I'm
hiding the uglies as much as possible.


> | But you're correct, this isn't a simple matter of storing an XML
> | document.  But simple queries of an already-merged topic map (such
> | as "get all topics whose base name is 'harrier' in the scope of
> | 'birds'" can certainly be done.
> 
> Sure, but those are really too trivial to be of much interest. A more
> realistic query is "show me all composers who have written operas based
> on works written by Shakespeare". It's not that complex, but I think
> you have to handle things up to that level *easily* to have a solution
> that's worth bothering with. (All IMHO, of course.)
> 
> | You just need to be sure that the TM engine is hooked into the DB
> | correctly when TMs are brought in and merges are requested. [I'm not
> | looking forward to this part of my future...]
> 
> Yeah, this isn't the easiest part of TMs to implement, exactly. Doing
> it efficiently and under memory constraints makes it even harder.


Sorry for the handwaving answer, but all of this I suppose will come
in good time. My engine right now does certain parts of the merging
process correctly, certain parts not correctly, certain not at all.
There's work to be done...

Murray

......................................................................
Murray Altheim                         <mailto:m.altheim @ open.ac.uk>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC