[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Some mails that didn't get through
Hi, As e-groups seems to have crashed I thought it might be best to just mail these around to whoever I could find in my XTM mail box. <<RE: [xtm-wg] Dynamic Generation and Serving of Topic Maps>> <<Scope and the WWWeb>> best Peter Peter Jones Systems Architect mailto:peterj@wrox.com Wrox Press - Programmer to Programmer (TM) http://www.wrox.com http://www.wroxconferences.com http://p2p.wrox.com
- From: Peter Jones <peterj@wrox.com>
- To: "'xtm-wg@egroups.com'" <xtm-wg@egroups.com>
- Date: Mon, 17 Jul 2000 12:24:00 +0100
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 _____ <http://click.egroups.com/1/6142/4/_/337252/_/963820158/> where you set the price <http://adimg.egroups.com/img/6142/4/_/337252/_/963820158/> _____ To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
- From: Peter Jones <peterj@wrox.com>
- To: "'xtm-wg@egroups.com'" <xtm-wg@egroups.com>
- Date: Mon, 17 Jul 2000 11:06:29 +0100
Hi, [Peter Jones] [Hard hats on please -- unfounded polemic to follow... ;-] I also have concerns that under these circumstances the mechanism for scoping as defined in ISO 13250 is both too strong and too insignificant. Too strong because scopes are defined as equivalent for two separate entities if the set of topic names given in the scope attribute's value is exactly the same. Too insignificant because, as I understand 13250, the value of the scope attribute is just a set of names. The type attribute is supposed to cure some of this but I don't think it does in a situation of the complexity I have outlined earlier (concerning the dynamic generation of a TM for dynamically aggregated resources over the WWWeb). Truth is there seem to be two separate things going on in 13250. One that says, "let's have a lot of the power of Concept Maps" and another that says, "let's just treat these docs as indexing docs and create a mechanism that suits merging indexes". (Chimaera or a pig with wings?). As we create XTM I am inclined to think that we need to merge more of the functionality of Knowledge Interchange Format with the 'aggregation over resources' capabilities. Scopes become defined more in terms of logical equivalence (with whatever truth model suits our needs best) of contexts as seen in Concept Maps. Its weak enough to allow more interesting and intelligent merger strategies and strong enough to keep scoping useful. The index view of a 13250 doc seems to be too much of a throwback to traditional libraries to me at this time. [You can take the hard hats off now.] I am just voicing intuitions at this stage and I realise that I need to play with topic maps more to provide more concrete data for decisions to be made, but I just thought it might be another useful minnow to introduce into the pond. [Peter Jones] cheers Peter
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC