RE: [tm-pubsubj-comment] Tuesday conference

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

Title: RE: [tm-pubsubj-comment] Tuesday conference

> -----Original Message-----
> From: Lars Marius Garshol [mailto:larsga@garshol.priv.no]
> Sent: Friday, May 03, 2002 11:08 PM
> To: tm-pubsubj-comment@lists.oasis-open.org
> Subject: Re: [tm-pubsubj-comment] Tuesday conference
>

Lars Marius, you've been asking some helpful questions.

> As it looks now the PubSubj recommendations will both allow and
> support that [i.e. using TM for PSI], but not require it, and perhaps not even recommend it.
>
> Do you think that is a problem?

For me the problem is: when we use a (retrievable) URL as a PSI, it should resolve in some structured definition, and the retriever should understand this structure in advance.

This is not absolutely neccessary, but it opens the door for any "intelligent agent" running through the semantic web. This will become crucial in the not so far future.

That is why I think we should fix this structure to be a topic map in the first step.

Second we have to think about HyTime and XTM and possibly more (writing a TM using RDF or XML schema) in a very political way and agree to one (1) common syntax for PSI purposes (not for *any* TM application), finally.

> 
> | 2 support both retrievable URL ("retrieval bookmarks") and URN
> | ("unique names only")
> | [...]
> | 4 allow diversity of data sources media across files, databases, or
> | whatsoever
>
> I certainly agree with both of these, though I guess we may disagree
> on what is actually needed in order to support them.

(a) There is one very concrete unsolved issue:
Using docs, we have the fragment identifier #myTopic.
Using data in a machine, we have the query ?id=myTopic.
Both will work and serve as a valid URI reference, but only in its dedicated media.
When the PSI set moves from doc to data or vice versa, the URI needs to be changed!
This is a remaining gap in the basic standardization (and de-facto application) of URI, but we have to suffer from it.

(b) in the TCs i see a general statement to support media diversity, but every day i find samples that people think file oriented only (or at least, first). I try to promote data-in-a-machine oriented thinking as an extension of awareness.

> 
> | 1 use Topic Maps for PSI sets
> | =============================
> | [...]
> | See the difference of saying "a topic map" from saying "XTM" ?
>
> Yes, but I don't see what you mean. What syntax is it you would like
> to see? That is, could you be more precise?

As i said above:
"... we have to think about HyTime and XTM and possibly more (writing a TM using RDF or XML schema) in a very political way and agree to one (1) common syntax for PSI purposes (not for *any* TM application), finally"

> 
> | 2 support both retrievable URL ("retrieval bookmarks") and URN
> | ("unique names only")
> |
> ==============================================================
> ===========
> | [...]
> | No doubt: A retrievable topic map fragment in this place is best!
>
> Why? That is, what would that fragment be used for?

We have had some discussion about this, but the thread fell asleep for a while:
What should be the content linked to a Topic-URI - be it PSI or not?
The answer: the identified topic in an XML syntax.
May be more: the topic and its associations - but those cannot be loose arcs, so you will need the associated topics as well. So one kind of useful topic map fragment may be:

1. one "centered" topic (the one identified by the URI).
2. all of this topic's associations.
3. all the associated topics.
I will suggest something like this in Barcelona - not going down to the syntax so far.

> | However, something like ISBN:0201175355 is a working published
> | subject without having any URL at all.
>
> I agree. The ISBN URN scheme is such that people can use it for
> subject identifiers right now, without any help from us at all.
> That doesn't help much for all the subjects out there that *don't*
> have a URN scheme yet, though. :)

I don't know what it takes to have an URN scheme, but basically it looks very simple.
Just find a unique acronym, such as XTM, and you have it.
"urn:xtm:myTopic"

I could get me one for myself:
"urn:tb:myPrivateTopic" - wonder if it would be uniq -
does someone really care for this? Uniqness is well defined for URL by the worldwide implemented domain name services (see some about it at http://www.iahc.org/dns-refs/).

Does anyone know wether there is something similar for URN?

> 
> | 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.
>
> Thomas, here I really don't follow you. What is it you mean?

To be short: I want the original XML topic map serialization to be human readable. Sure, the reader will have to learn a little about what he is going to read. The XML syntax should take care about this problem. I think XTM is not very handsome in this field.

> | 4 allow diversity of data sources media across files, databases, or
> | whatsoever.
>
> I agree we should do this, but what, in all that we've done so far, is
> it that really poses a threat to this in any way? I really don't
> understand what your concern is.

I have answered this above.
My concern is to propose a well defined application of a topic map for PSI, so that the onto- and semantic folks all around will say: hey this is something useful.

Hope i could clarify what i mean at least a bit.

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