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: [xtm-wg] Dynamic Generation and Serving of Topic Maps


2 approaches:
 
1) Computing a new TM from pre-existing TM does not necessarily make the pre-existing ones visible as part of the new TM. The application could nevertheless remember the computation in some way, and allow the pre-existing TM to be accessed *if required*.
 
2) The new TM could refer to parts of the pre-existing TMs as *resources* within its own map. Then the application would have no compulsion to regard them *as TM*, so reducing various overheads on processing. Again, the full shebang could then be dug out if required, piece by piece (depending on the application supporting such goings-on, of course...)
 
Cheers
 
Ann W.
-----Original Message-----
From: Peter Jones [mailto:peterj@wrox.com]
Sent: 16 July 2000 21:09
To: 'xtm-wg@egroups.com'
Subject: [xtm-wg] Dynamic Generation and Serving of Topic Maps

Hi,

Here are some concerns that I'd like to put to the AG before the next meeting. The issues I address here might have been covered by HyTime (with which I am yet to familiarise myself) where ISO 13250 is concerned but I want to see if we need to import new ideas into XTM.

To go back a few steps...

I discussion with JackP, whilst Jack acknowledged the issue of the 'late binding' of visualisation to topic maps he remained concerned about memory/bandwidth issues with regard to processing TMs for visualisation, particularly where both server and client resources might be severely limited. I want to borrow that point and raise a concern about the processing or generation of TMs for dynamically constructed aggregates of resources. I think that it is a point of high importance for XTM as the WWWeb becomes an ever more fluid flow of data from one place to another.

Imagine, if you would, the following scenario:

Assume that I have a tool that is a lot like a search engine, that fetches a pile of interesting media of one format or another in response to a query. Assume also that the pile fetched has no coherent TM already defined for it in a single TM document somewhere, but that each bit of stuff is referred to in various TMs' topics and associations. At the same time as the pile of stuff is fetched for me I want to have a minimal TM constructed for it, one that covers only those topics referred to in this set of stuff and any relevant associations that I can grab.

Q. How do I construct that minimal TM? I.e. how do I get the parts that might reside in fifty or more separate TM docs, given that I only want to grab those parts, without shoving the entire set of fifty+ docs through my XTM processor to get there?

(This scenario applies just as much for a search engine with one huge already-constructed TM only needing to serve up a small part to your client media browser, I think.)

Does it make sense to suggest something like the following, that we should have in the XTM spec something like an 'import-from' or 'include-from' tag set or attribute set,

e.g. (shown as elements here...)

<topicmap_xtm>
  <import-from href="http://somewhere.net/blah/a_tm.xml">
    <topic-list>
       <topic-name>Foo</topic-name>
       <topic-name>Bar</topic-name>
    </topic-list>
    <assoc-list>
       <assoctype-name>Glue</assoctype-name>
       <assoctype-name>Glue</assoctype-name>
    </assoc-list>
    <facet-list>
       ...
    </facet-list>
  </import-from>
</topicmap_xtm>

This also has implications for what conforming XTM processors should be able to do(?) .

Any thoughts?

best,

Peter

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

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


where you set the price

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