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

[Dan Brickley <daniel.brickley@bristol.ac.uk>]

(back on the RDF and topicmaps theme again; I refrained from changing
the subjectline though)

On Fri, 3 Nov 2000, Steven R. Newcomb wrote:

[...]
>
>   Let me say this again in a different way.  
> 
>   Topic map documents, including XML documents that conform
>   to the XTM Specification, are utterly unreliable tools for
>   every purpose except interchanging and reconstituting
>   topic map graphs.  Topic map graphs must be created from
>   topic map documents before the information contained in
>   the topic map documents can be made available for any
>   useful purpose.

That's a familiar sounding message. We've been through this fairly
recently with RDF. Because we use XML to encode RDF data structures,
everyone expects (seems so reasonable!) that XML APIs, transformation
languages (XSLT), query systems etc. will work out-of-the-box for RDF
applications. IMHO the Cambridge Comminique note
(http://www.w3.org/TR/schema-arch) goes some way towards articulating
why this isn't the case. RDF needs to be processed as RDF; we don't look
to XML query languages and APIs to do this work in the same way that we
_use_ Unicode but we don't try using a Unicode API or query language to
build RDF applications. I believe topicmaps to be in the same situation.

> 
>   Let me say this again in a different way.  
> 
>   Anyone who thinks that they can use the DOM to gain direct
>   access to the information contained in topic map documents
>   is totally in the dark about the nature of topic maps and
>   about the meaning of the information contained in topic
>   map documents.  BEWARE OF THIS GRAVE ERROR.  It is based
>   on a false assumption that is pervasive in Web-land, and
>   this is the reason why the error is so very common.  

Without wishing to get into a pass-the-blame discussion, I would
substitute 'XML' for 'Web' here. The excitement around XML has led too
many to conclude that the DOM/Infoset level is the right place to do all our
work. Lots of information systems (RDF, topic maps, UML...) can make
great use of XML without pushing query, APIs etc down to the syntax
level. 

>    The false assumption is that the syntax of an XML document is
>   also always the API to the information that it contains.

[nods vigourously]

That doesn't preclude their being other generic XML-oriented APIs that
might be useful in this way. 

>   While that assumption may work for comparatively simple
>   kinds of information, it cannot work for n-dimensional
>   information.  Topics are inherently n-dimensional.  The
>   connections between topics are inherently n-dimensional.
>   The conections between the connections between the topics
>   are inherently n-dimensional.  Etc.  Any interchange
>   syntax for topic maps necessarily squashes all these
>   dimensions into a single string.  There is not now, nor
>   can there ever be, any practical way for topic map
>   information, which is inherently multidimensional, to be
>   represented as a single string of characters in such a way
>   as to allow applications to skip the step of
>   reconstituting the topic map graph and still understand
>   the information contained in the topic map document.

That's a really nice way of putting it. A while back I helped scribble
http://www.w3.org/TandS/QL/QL98/pp/enabling.html which makes a similar
point in terms of logical vs physical models. Lately I've found it more
persuasive to couch the problem in terms of XML data aggregation: we'll
often want to query the aggregate of several XML documents, so the
argument goes, and therefore we need an abstraction over and above the
individual documents that contain fragments of the entire picture. I
don't know enough about topic maps aggregation yet to know whether the
same story applies; I'd like to think it does.
  

>   Objection: So, how can we get topic maps onto the web if
>              they have to be interchanged and then wholly
>              processed by their recipients before they can
>              be used?  That idea won't scale!
> 
>   Answer: XTM 1.0 won't answer this very good question.  XTM
>           1.0 will provide a syntax for the interchange of
>           topic map graphs, it will describe what a topic
>           map graph is, and it will describe the process by
>           which an interchangeable XML topic map can be
>           reconstituted as a topic map graph.
> 
>           After XTM 1.0 is published, our next task is to
>           describe how to support interactions with
>           remotely-maintained topic map graphs via the Web.
>           Please be patient.  We're moving as fast as we
>           can.  Your question about how topic maps can be
>           scaled up and accessed remotely will be answered.
>           Just be informed that the remote access to topic
>           map graphs cannot be via the DOM.  The DOM
>           provides access to the properties of parsed XML
>           documents, but not to the properties of topic map
>           graphs.

[ cheering from the sidelines ]

If this is where you're up to in the topic map roadmap, I'd urge
implementors to take a look at the various APIs for RDF that have been
proposed. Maybe they'll work for topic maps, maybe they won't. Now seems
like a great time to find out. I link to a number (not all -- several
announcements to www-rdf-interest since August remain uncatalogued) of
RDF API docs from http://www.w3.org/RDF/Interest/#docs  
They all do similar things: offer a graph-oriented view of the results
of parsing RDF from one-of-various XML encodings. I'd love to know
what kind of APIs folk have been using for topic maps, and how these
compare. Does anyone have a URL for something like this...?

cheers,

Dan


-------------------------- eGroups Sponsor -------------------------~-~>
Create your business web site your way now at Bigstep.com.
It's the fast, easy way to get online, to promote your business,
and to sell your products and services. Try Bigstep.com now.
http://click.egroups.com/1/9183/4/_/337252/_/973273607/
---------------------------------------------------------------------_->

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

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