[tm-pubsubj-comment] Tuesday conference

["Bandholtz, Thomas" <thomas.bandholtz@koeln.sema.slb.com>]

Title: Tuesday conference

PSI-junkies,

the last weeks I have followed discussions with what Bernard has labelled "mixed feelings".
I called in to the Tuesday conference in this state of mind, not beeing sure about my statement.

So I started just listening. After one and a half hour suddenly I suspected the group (including myself) was commiting a fatal basic error. We were discussing questions of the internal structure of a PSI doc on a very abstract level. One item led to another, and I found ourselves amidst a haystack of unsolved "issues", feeling very small and far, far away from our objectives.

And suddenly I remembered that most of the issues can be solved easily when we use a topic map for the PSI doc. I remember the resulting protest - OK I know we had this discussion before.

But I want to raise this question again, after having had some experience with the consequences of *not* chosing topic maps.

Actualy now I have four statements:

1 use Topic Maps for PSI sets

2 support both retrievable URL ("retrieval bookmarks") and URN ("unique names only")

3 integrate human and machine readability in one source

4 allow diversity of data sources media across files, databases, or whatsoever

For those who are interested, here is some closer reflection (I do not want to relegate these thoughts to be some other "issues" :-)

 
1 use Topic Maps for PSI sets
=============================

Note I do not say "XTM". The internal structure of a topic map is capable to accommodate a PSI doc. There are some issues not completely solved yet, but I see no restriction of feasability.

It is our strength that we can offer a structure capable of doing so, and we should not hesitate to communicate this. As I have said during the conference, rather spontaneously, "everybody will think: they don't even believe in topic maps themselves".

On the other hand, the possibly interested communities outside the TM crowd may see this as a restriction. I think the restriction will be even harder when we propose common use of PSI and not even provide a concrete structure definition.

This concrete structure definition should be a topic map - what else? If someone prefers a different structure, (s)he should argue for it. In this sense, RDF is not a different structure for a PSI doc, but just a different syntax. Why not write a topic map using RDF?

See the difference of saying "a topic map" from saying "XTM" ?

2 support both retrievable URL ("retrieval bookmarks") and URN ("unique names only")
====================================================================================

read http://www.w3.org/TR/2002/WD-xml-names11-20020403/ about namespace names:
"[Definition: The attribute's value, a URI reference, is the namespace name identifying the namespace.] The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). An example of a syntax that is designed with these goals in mind is that for Uniform Resource Names [RFC2141]. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals."

No doubt: A retrievable topic map fragment in this place is best! However, something like ISBN:0201175355 is a working published subject without having any URL at all.

3 integrate human and machine readability in one source
=======================================================

XML was intended to be both. Though I would consider myself to be a machine-head i see it as a question of professional ambition to make everything as human readable as possible. On the other hand, doc-heads should not be too comfortable. TM need not to be fairy tales.

4 allow diversity of data sources media across files, databases, or whatsoever.
==============================================================================
XQuery 1.0: An XML Query Language, W3C Working Draft 30 April 2002
http://www.w3.org/TR/2002/WD-xquery-20020430/
"XML is a versatile markup language, capable of labeling the information content of diverse data sources including structured and semi-structured documents, relational databases, and object repositories. A query language that uses the structure of XML intelligently can express queries across all these kinds of data, whether physically stored in XML or viewed as XML via middleware."

Thomas Bandholtz
CM / KM Division Manager; XML Network Moderator
Competence Center Content Management
SchlumbergerSema
http://www.schlumbergersema.com

Kaltenbornweg 3
D50679 Köln / Cologne
Germany
+49 221 8299 264

PS: Bernard, how was May, 1st in France?