[sc34wg3] TMQL Enterprise Information Integration

[Patrick Durusau]

Rani,

Rani Pinchuk wrote:
> Dear Patrick,
>
> I cannot see how this feature is related to TMQL.
>
>   
Well, it was thought quite relevant at the time the original use cases 
were generated and I haven't seen anything that would alter my opinion 
about its relevance.
> If I understood what you mean, we call it Integration Layer. So to 
> create a Topic Maps "view" over (for example) several different 
> relational databases. That means that at least part of the data in the 
> topic map comes from different data stores.
> I know that Lutz Maicher is interested in this. Robert Barta called this 
> Topic Maps bridges (as far as I recall). We also played with this idea 
> in one project, and plan to go a bit further with this in the future.
>
> However, the whole point in the integration layer is that it does not 
> affect the Topic Maps tools and APIs you use. So you keep using the very 
> same TMQL you used to use over your topic maps, just that behind the 
> scenes, parts of the topic map are spread over different data stores.
>
>   
And how do you propose in TMQL to view the different data stores if, say 
for example, TMQL could only speak of topics, associations and occurrences?

Doesn't leave much room for addressing other data structures as though 
they are "topics, associations and occurrences."

The current draft, which I know isn't popular reading material, answers 
that question by positing a tuple structure which can then be addressed 
by any TMQL implementation as topics, associations and occurrences.  (I 
am using "topics, associations and occurrences" as a short hand for any 
relevant topic map constructs and not by way of limitation.)

So I think this has profound implications for the shape of TMQL.

Hope you are having a great day!

Patrick


> Kind regards,
>
> Rani
>
>
>
> Patrick Durusau wrote:
>   
>> Greetings!
>>
>> There is also a wealth of useful TMQL information in the use case 
>> document: http://www.itscj.ipsj.or.jp/sc34/open/0449.htm.
>>
>> One in particular that I would like to single out goes by the unlikely 
>> term *immaterialized topic map.*
>>
>> Fortunately the reader doesn't stumble over that bit of phraseology 
>> until fairly late in 3.4, Enterprise Information Integration.
>>
>> In a nutshell this section restates the obvious point, lost on a number 
>> of other data integration strategies, that converting existing archives 
>> to some new format to achieve data integration works, but at great cost 
>> and risk to the original data. So much so that it happens but not often.
>>
>> The point here is that existing information archives can be viewed "as 
>> though" they were topic maps and so subject to the same merging rules as 
>> any other topic map, up to and including additional merging rules.
>>
>> There was a recent post about the use of topic maps in libraries to 
>> FRBRize their catalogs. Given that most such catalogs are already held 
>> in deeply embedded data structures on which other systems rely, the 
>> ability to view them "virtually" as topic maps offers an low threat 
>> level way to demonstrate the value add that topic maps brings to an 
>> information system.
>>
>> I would rank this in the "must have" requirements for TMQL.
>>
>> Hope everyone is having a great week!
>>
>> Patrick
>>
>>     
>
>   

-- 
Patrick Durusau
patrick at durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)