- From: Graham Moore <gdm@empolis.co.uk>
- Date: Wed, 27 Jun 2001 14:42:49 +0100
- To: <www-rdf-interest@w3.org>
k42 provides a graph view of topicmaps as part of the k42 engine. The DTD used is called TMV (Topic Map View) and can be accessed via the k42 topic map server. The DTD is part of the k42 download. I'll post it somewhere public to avoid people having to download it. At the time of development I just saw it as nice way to give developers access to topicmap data in a useful XML way - XTM is not useful for building scalable applications. I'm sure we can all imagine the issues there! Not only does this model provide a graph representation of Topic Maps by being able to follow from one node to another. It provides a server that can retrieve fragments of this graph from a processed topic map using TMQL. I make this point as I see 2 standards activities that need to happen in conjunction with TMQL. 1. A coming together of the graph DTDs, TMV and TopicMapGraph 2. a protocol for retreieving these fragments from a TopicMap Server. Thus giving us a framework for distributed topicmap servers. If you want more information on the notion and requirement for the distributed topic form see the TMQL requirements document that I submitted that talks about distributed result sets. While I think TMV and TopicMapGraph are useful tools - they allow rapid development of applications that deliver custom views of a topic map. I think we must realise that they are tools not yet a definition of the model. We have a process now at ISO for describing the model of topicmaps - i think we do, and It is quite clear that the XML graph representation will fall out of that work. So I see in that TMV and TopicMapGraph are contributors / suggestions as to what the internal model will look like. I think the levels that Steve and Michel have developed ties in nicely with what has been discussed on the issue of APIs and the requirement for several layers of API. Right - I'm off to play with extending k42 to have a TopicMapGraph component as well as TMV. And work out what the differences are. cheers graham -----Original Message----- From: topicmapmail-admin@infoloom.com [mailto:topicmapmail-admin@infoloom.com]On Behalf Of Michel Biezunski Sent: 27 June 2001 12:25 To: Topicmapmail@Infoloom. Com Subject: [topicmapmail] ANN: Topic Maps Graph and API in XML To all: We announce the availability of two DTDs for describing the Topic Maps Graph at http://www.topicmaps.net (see details at the end of this message). We'd like to share with you the results of a couple of thought experiments we've been doing recently. In Berlin, Jonathan Robie asked a very good question about Topic Maps, which we would like to paraphrase as follows: "If the XTM DTD is for interchanging topic maps, why can't instances of the XTM DTD be directly queried using XQuery to use whatever information the topic map has to offer?" Steve N. vigorously defended the idea that, while a fully-processed topic map graph is queriable, a raw XTM instance is not queriable without first transforming it (and the topic maps that it includes by reference) into a topic map graph. But, later, Steve was troubled by the sheer good sense of Jonathan's plea that, if you're going to use several syntaxes to interchange a certain information set, *at least one of them* should be absolutely reflect the true structure of the information, so that, for example, XQuery can be used to access the information. Why shouldn't there be a syntax for interchanging fully-processed topic map graphs? Meanwhile, Michel B. continued to be troubled by the fact that still there are still so few people who appreciate the comprehensiveness and simplicity of the structure of topic map graphs as proposed in http://www.topicmaps.net/pmtm4.htm. Michel wondered whether modeling a topic map graph by providing an interchange DTD for topic map graphs would help people understand the nature of topic map graphs more easily. Steve N. was taken aback by Michel's proposal, because it resonated so strongly with the reasonableness of Jonathan's plea. It also occurred to him that, given the right XML interchange structure for topic maps, no special API would be needed in order to use a topic map graph. The simplest DOM API would be a perfectly adequate topic map browser, if only the XML rendition of a topic map graph would be designed in such a way as to support the browsing of topic map information. So, this is our report that we have written two very different DTDs, both of which are theoretically for the purpose of interchanging topic map graphs, or for publishing ready-to-use topic maps on the web. One of the DTDs, "simpleTMGraph3.dtd", is probably pretty close to being the simplest and least redundant way to comprehensively represent a topic map graph in XML. This DTD will be interesting (and brief) reading for anyone who wants to know the structure of topic map graphs, and who is already familiar with the DTD formalism. Every node is an element, and every arc is also an element. The arcs do all the referencing -- each arc references the nodes that, in the topic map graph, appear at their ends. The second DTD, "TMGraphAPI3.dtd", is more practical and more complex. Its instances contain much redundant information. The redundancy stems from the fact that this DTD is designed to allow simple non-indexing DOM applications to browse the XML instance as if it were a topic map graph. The structure of the document instance itself constitutes an API to the information contained in that instance. Every element that represents a node (such as a topic node) contains all of the references to all of the other nodes that would normally be connected to that node via the arcs. For example, in an instance conforming to TMGRaphAPI3.dtd, each element that represents a scope node contains references to all of its component topics, *and* each of the elements that represents one of its component topics *also* contains a reference back to the scope node. These mutual references allow the simplest DOM applications to browse from node-representing element to node-representing element, just as if these applications were following the arcs of a topic map graph. DISCLAIMER: These DTDs have no official status of any kind in any context. We hope they will help to enlarge the public conversation about the essential nature of topic map information. URLs: http://www.topicmaps.net/index.htm gives orientation to the files below: http://www.topicmaps.net/struct.htm : structure of topic map foundations http://www.topicmaps.net/simpleTMGraph3.htm: a Topic Maps Graph, in XML http://www.topicmaps.net/TMGraphAPI3.htm : an API to a Topic Maps Graph, in XML Corresponding text versions of the DTDs (without explanations) can be found at: http://www.topicmaps.net/simpleTMGraph3.dtd: a Topic Maps Graph, in XML http://www.topicmaps.net/TMGraphAPI3.dtd : an API to a Topic Maps Graph, in XML Michel Biezunski and Steven R. Newcomb ========================================== Michel Biezunski, InfoLoom Tel +33 1 44 59 84 29 Cell +33 6 03 99 25 29 Email: mb@infoloom.com Web: www.infoloom.com ========================================== Steven R. Newcomb, Consultant srn@coolheads.com voice: +1 972 359 8160 fax: +1 972 359 0270 1527 Northaven Drive Allen, Texas 75002-1648 USA ========================================== _______________________________________________ topicmapmail mailing list topicmapmail@infoloom.com http://www.infoloom.com/mailman/listinfo/topicmapmail _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Received on Wednesday, 27 June 2001 09:42:00 UTC