Re: [tm-pubsubj-comment] Tuesday conference

[Bernard Vatant <bernard.vatant@mondeca.com>]

Thomas

Certainly I will repeat myself here. All that stuff I've already scattered in several
messages in this or other forums archives. But it will be quicker for me to repeat than to
browse the archives for it :))

Steve have come lately to the conclusion that Topic Maps is not a good option for PSD, out
of technical considerations.
My view has been the same from the beginning of this TC process, but out of both political
and conceptual arguments.
It's interesting to notice that we get to the same conclusion from different ways.

The political arguments I've already stressed. Locking PSIs in Topic Maps realm and
technology is certainly not a good move if we want wide-spread and quick adoption. We are
not sure at all of wide-spread adoption of Topic Maps technology, but I'm strongly
convinced that Published Subjects have a potential scope of application much wider than
Topic Maps, even if it's currently difficult to figure what is or will be the exact
extension of that scope.

The conceptual argument I want to repeat, because I think it is the most important one.
Published Subjects ambition is to build a bridge between the "formal addressable" universe
(where Topic Maps belong) and the "unformal non-addressable" universe of real world
subjects (where publishers and users leave). Steve Newcomb speaks (in its chapter of the
to-be published book on Topic Maps) of two cliffs separated by this chasm that everyday's
use of language and conversation is bridging efficiently, but that is very difficult to
bridge in our information systems. When I speak of Janus Bifrons looking inside and
outside the doors, in the gentle introduction to Published Subjects, I think I am speaking
about the same thing.

If we use Topic Maps for definition of Published Subjects, we are putting them on the same
"left-hand" cliff of the chasm, and all difficulty may disappear indeed, because it's not
a bridge anymore.

We have strong foundations on the left-hand side (including, but not only, topic maps). We
have hard time to figure the foundations on the other side. Sure enough. But wanting to
build a bridge from one side only looks to me like being the fool searching for his keys
on the lightened side of the street - because it's easier to search in the light -
although he knows he lost them on the dark side.

Regards

Bernard

PS : We shall overcome ... :))

----- Message d'origine -----
De : "Bandholtz, Thomas" <thomas.bandholtz@koeln.sema.slb.com>
Ŕ : <tm-pubsubj-comment@lists.oasis-open.org>
Envoyé : vendredi 3 mai 2002 09:24
Objet : [tm-pubsubj-comment] 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?