["Bandholtz, Thomas" <Thomas.Bandholtz@koeln.sema.slb.com>] RE:[tm-pubsubj-comment] Tuesday conference

[Lars Marius Garshol <larsga@garshol.priv.no>]

I'm forwarding this email from Thomas. Judging by the first line it
wasn't meant for me only.

--- Begin Message ---

• From: "Bandholtz, Thomas" <Thomas.Bandholtz@koeln.sema.slb.com>
• To: "'Lars Marius Garshol'" <larsga@garshol.priv.no>
• Date: Fri, 10 May 2002 09:52:29 +0100

Lars Marius, and anyone possibly interested, sorry for the delay.

> So the requirement that you want satisfied is that it should be
> possible to get at the core published subject assertions[1] from the
> published subject identifier (URI)?

Exactly - without any statement about [1] currently.
I would not introduce the term "published subject assertions".
ISO 13250 clearly defines "topic topic characteristics" this is all we need.
We should not start with Adam & Eve again and again.

> I think that's a requirement we should try to fulfill, but that
> doesn't imply that the URI has to resolve to an XTM document.

I did not say XTM. I said Topic Map.

> Instead, we could define conventions for how HTML/XHTML documents can
> refer to the XTM/RDF documents that contain the published subject
> assertions. 

This will not work for a machine. There must be a clear formal syntax.

> | 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.
> 
> I am not sure what you are saying here. Are you saying that you would
> like to see another topic map syntax in addition to HyTM and XTM? Or
> you saying that we should agree to always let the URI resolve to
> either HyTM or XTM?

I want to quote Jim Mason here. You have read this before:

"We need to keep clear that the transfer serializations are not the
definition of Topic Maps: The standard is the definition. SC34 intends that
the supplementary standards will clarify the meaning of Topic Maps without
changing their essential nature. (We also recognize that other transfer
serializations are possible, outside the standard.)"

I have discussed this a little in
http://195.14.240.28/123/03-05-03.html#S8.1 


> If we choose to be more flexible we can say:

We should not be flexible, we should be clear.

> 
>  - if the URI resolves to XTM, that's fine,
> 
>  - if the URI resolves to HyTM, that's OK,
> 
>  - if the URI resolves to HTML, the HTML document can declare multiple
>    alternative topic map syntaxes, and
> 
>  - if the URI resolves to something else, that's fine, but you won't
>    necessarily be able to get at the published subject assertions.

If the URI resolves to a Topic Map, that's great!

> | (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.
> 
> This is a misunderstanding, but a common one. When you publish
> something on a web server *you* decide how the URIs map to resources,
> so it's fully possible to avoid this problem. In any case, this is not
> a problem with published subjects, but a general URI management
> problem.  

Right, a "general URI management problem". We have discussed this in the
thread named "referring to a topic fromoutside a TM ". Try fragment
identifiers against XML with any relevant tool. This will not work. Neither
in IE6, nor in Java Servlet. From inside a Java Servlet you cannot access
what comes behind the #. This is not a bug. I have discussed this in 
http://lists.oasis-open.org/archives/topicmaps-comment/200203/msg00037.html

> | (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.
> 
> I think that's good. We have a tendency to say "file" when we mean
> "resource", but I don't think this will be a problem with our end
> product. 

It will be as long as a we think of files when we say "resource".

> ... I don't this is a very good idea, actually. Extracting topic map
> fragments is not easy, 

Why?

> and if we require this of people it would mean
> that there's a high technology threshold for people to be able to
> publish subjects.

Did you ever think about the threshold we produce by trying to be "flexible"
?

> I also don't think fragments are that much more useful than the full
> topic map.

Associations are part of "topic charasteristics". (Now and then all of us
should re-read good old ISO13250). If I include associations, I need to
include the associated topics as well. No need to include the whole TM.

> | I don't know what it takes to have an URN scheme, ...
> You would have to use "x-tb" to follow rules, and then there would be
> no guarantee that the result would be unique.

Thank you. This was useful information. I'll come back to it later.


> | 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.
> 
> Do you mean "the XTM syntax should be made more human-readable"? 

Yes.

> With
> me, any proposal to change that syntax is a non-starter, and I think
> most people feel the same way. Stability of the syntax is much more
> important than anything else.

Again, I have discussed this a little in
http://195.14.240.28/123/03-05-03.html#S8.1 

Thomas

--- End Message ---

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >