Re: [tm-pubsubj-comment] Tuesday conference

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

* Thomas Bandholtz
| 
| 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.

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)?

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.
Instead, we could define conventions for how HTML/XHTML documents can
refer to the XTM/RDF documents that contain the published subject
assertions. 

| 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?

If we choose to be more flexible we can say:

 - 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.
 
| (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.  

| (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. 

| 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.

I don't this is a very good idea, actually. Extracting topic map
fragments is not easy, 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.

I also don't think fragments are that much more useful than the full
topic map.
 
| 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"

It takes a bit more than that. You need to get it registered, and the
IETF is pretty strict with what they register. Fortunately, there are
some very interesting proposals currently on the way:

  <URL: http://larry.masinter.net/duri.html >
  <URL: http://www-nrc.nokia.com/sw/draft-pstickler-voc-00.html >
 
| 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/).

You would have to use "x-tb" to follow rules, and then there would be
no guarantee that the result would be unique.

| 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"? 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.

In any case I don't think it is realistic to get the average reader to
be able to read an XML-based formal syntax, nor do I see any point in
it. If the requirement behind this wish is the one I formulated above
there are other ways to satisfy it.
 
| 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.

Hmmmm. What do you mean by this? A set of published subjects for PSDs
in order to encode metadata? A new syntax, or something else? If so,
what would the purpose of the syntax be?

[1] <URL: http://www.oasis-open.org/committees/tm-pubsubj/docs/lmg/analysis.html >

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