RE: [xtm-wg] Dynamic Generation and Serving of Topic Maps

[Peter Jones <peterj@wrox.com>]

Hi,

 

I think what I'm driving at is that 1 sounds like something the server system would do, and something like 2 is what the user client would have to operate with.

 

I would be aiming to reduce the amount of processing required on the server and the client, something like making derived documents capable of simply being a set of references, and the construction of those documents taking place without full parsing of the source TMs (query statements over structured docs that are then repeated in the client doc, rather than the client doc containing all the results of the queries in full, this then giving rise to in-memory structures that can be merged and validated on demand).

 

Wrt 2 and what I am driving at: I might be missing something but is there exisiting provision for this in the ISO 13250 spec?

 

Separately: Where is the reference made to the parts of the pre-existing TM for these *resources*? If they are referred to within the map then doesn't that mean that they are a level of nesting below the main occurrence references of the map, sort of? That doesn't sound healthy.

 

cheers

Peter

-----Original Message-----
From: Wrightson, Ann [mailto:Ann.Wrightson@sweetandmaxwell.co.uk]
Sent: 17 July 2000 08:49
To: 'xtm-wg@egroups.com'
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

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

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

---

---

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

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