OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [tm-pubsubj-comment] formal syntax (was: Tuesday Conference)

* Thomas Bandholtz
| I think we should concentrate on developing *one final* syntax for
| topic maps, and we should also use it for PSI, as PS are topics.

OASIS can't develop a new syntax for topic maps. That is ISO SC34
territory, and none of the OASIS TCs have it within their charter to
go there, nor do I think they wish to.

Most people are happy with XTM, and see no need for a new syntax. I am
very much in this camp, myself. XTM was developed based on real-world
experience, and has stood the test of time (so far) very well indeed.

That we should also use one TM syntax for assertions about published
subjects I agree, and I would like to see that syntax be XTM. I don't
think all published subjects necessarily need to be published in a
formal syntax, however.

This document, for example, contains a number of published subjects,
and is used as such in a real topic map.

  <URL: http://www.oasis-open.org/committees/geolang/docs/todo.html >

| Currently we only have two recommended interchange formats, and we
| are going to develop a third something about PSD.

No, it is not clear that there will be a third for PSDs.

Also, HyTM is *not* recommended. As far as I know, hardly anyone uses
it, and I wouldn't recommend anyone to use it.
| Generally I think XTM is far too abstract. It is a worthy
| contribution, but - as I heard some W3C fellow say Wednesday, in
| Luxembourg - you cannot standardize too fast. It takes some time to
| experiment, and you have to watch your first attempts fail before
| anything can become mature.

Well, it was created based on experience, and a number of people have
been using it for more than a year now, with very little complaints
coming in so far.

What do you mean by "too abstract," by the way?
| I know there are more approaches than only two. Did anybody read
| http://www.diffuse.org/TopicMaps/20001221/schema.html, for example?
| This is Martin Bryan's approach (yes, Martin who has been one of the
| authors of SGML, and of ISO13250 :-)

Yes, I've read it. I think it is misguided. Creating an XML syntax
specifically for one topic map application is an acceptable thing to
do, but so what? All you need is some way to define a mapping from it
to XTM, and whether you use architectural forms, XSLT, Python scripts,
the Ontopia MapMaker Toolkit, or something else is your business.
| I do not believe that Martin has given us the final solution. But
| some of his ideas provide us with something that XTM is missing,
| i.e. seperating typology from topics.

Careful now, Thomas. You have to carefully distinguish the syntax from
the model. In the model types are topics. Are you unhappy about that?
If so, why? If you are satisfied with the model, then what does it
matter what the syntax does? It's just a serialization of the model.

| My (our) problem is: there is no discussion about things like this.

There is a very simple reason for that: we did these discussions back
in 2000 and early 2001. We are done with them now. All that remains is
firming up the work that was done then, and ISO SC34 is currently
doing that with its model work.

If you have input on the model and syntax work I think what you should
do is to involve yourself in the ISO work. The first step would be to
read the following, in this order:

  1) The new roadmap to the ISO standards work, intended to replace
     <URL: http://www.y12.doe.gov/sgml/sc34/document/0278.htm >
     (not published yet, sorry)

  2) The latest SAM model draft, at
     <URL: http://www.y12.doe.gov/sgml/sc34/document/0299.htm >

  3) The Reference Model description, at
     <URL: http://www.y12.doe.gov/sgml/sc34/document/0298R1.htm >

After that you may want to join the SC34 mailing list, and get

| Looks like we prefer to open new road works before we have
| closed those already in progress. 

Not so. The "syntaxes for topic maps" work *is* closed. As far as I
know the only person who would like to restart it is you.

| I.e. why do we need a definition of "psi assertions" if we have a
| very good definition of Topic Characteristics. 

That's a good question. I chose "assertions" because it was
independent of topic maps. I agree that you could say this:

  [foo = "Subject assertions"
       = "Topic characteristic assignments" / iso-13250]

| Did we really read ISO 13250 ?
| http://www.y12.doe.gov/sgml/sc34/document/0129.pdf (currently this
| results in a 404 error, not so nice, but I have a local copy that I
| would send to anybody really interested).

The Barcelona meeting approved a new version of that document which
includes all the amendments made since the original publication. This
will appear under 322 (as PDF, probably, not HTML) on this page as
soon as Jim comes back to the US and starts clearing up after the

  <URL: http://www.y12.doe.gov/sgml/sc34/document/0350.htm >
| Why do we hezitate to advice the interested folks to use one (1)
| formal syntax?

Because it forces them to use topic maps, because it may not be
necessary for them to go quite that far (cf. the todo document linked
to above), and because the less we require of people the more likely
they are to follow our recommendations.

Look at what happened to RSS, for example. Or read "worse-is-better".
(In fact, all of us should re-read "worse-is-better" at least once a
| Imagine you just learned about a new standard, and you say: Well,
| sounds great, I will try to use it. And then they say: yor can do it
| this way, or you can do it that way, .....
| We hezitate because we do not have a formal syntax that we believe
| to be persuasive enough for the possibly interested community. So we
| say: use any syntax you like. *Nothing* will work this way.

Here I think you are misrepresenting the view taken by the TC. 
| Finally I start to think this is a waste of time. ISO 13250 clearly
| defines "public subject descriptor". Where have we gone trying to
| elaborate the little difference to "published subject identifier"?

There is actually a major difference, and so far it seems that the
introduction of that new term has helped quite a lot. There are three
terms here, and two subjects:

  a) "public subject descriptor"

     This term was defined by ISO 13250, and while I think there is
     nothing wrong with it, XTM 1.0 replaced it by "published subject
     indicator", as part of the reworking of subject identity

     This term is effectively dead.

  b) "published subject indicator"

     This is essentially the replacement of "public subject
     descriptor," and is widely used and understood today. "Public
     subject descriptor," on the other hand, is as good as forgotten.

     In short, this is the term to use.

  c) "published subject identifier"

     This is the *URI* of the indicator, and *not* the same as either
     "public subject descriptor" or "published subject indicator".
     The rationale for introducing this term is that it helps make
     some very important distinctions clear that people tended to
     obscure before.

     In short, use this term when appropriate.

Does this help?

| There are lots of folks outside what Bernard calls our "realm". All
| of them would love to find a solution about unique semantic
| identifiers. Some have found a feasible way to go (like ISBN, IATA,
| ...). I think they won't care about us.

You do have a point here. The RDF people need a solution to this,
people outside the RDF/TM communities have shown interest, and, as you
say, for ISBNs a different solution has been found. (That is an issue,
and needs to be considered[1].)

I think that if we do this right then the RDF people will just adopt
our solution. A number of them have made unofficial statements to that

However, if we require everyone to use a topic map-specific syntax to
create published subjects I'm afraid we will scare away both the RDF
people and those outside the RDF/TM communities.

| I have written a TM Schema myself as well. But I don't think it is
| even worth to be discussed as a standardization proposal, it is just
| good enough to be the working data model of my engine. No problem to
| use any interchange format for interchange purposes (thanks to XSLT,
| owning a clear formal syntax to specify syntax transformations).

Exactly. So why are you unhappy about XTM?
| I have visited the "Knowledge technologies and digital content"
| workshop of the European Commission
| (http://www.cordis.lu/ist/fp6/workshops.htm) last Wednesday. Lots of
| Ontology people there. What can we tell them? "Add some assertions
| to your subjects"? Those people are not stupid. How do we refer to
| their discussion? How do we refer to RDF? What is it we have and
| they have not? What is it they have and we have not?

I don't think we need to go into that at all. Published subjects is
about establishing globally unique, stable, and well-defined
identifiers for abstract subjects. That is actually independent from
making assertions about those subjects. So the thing to tell them
would be "create identifiers for your subjects." Making assertions is
the second step.

[1] <URL: http://www.y12.doe.gov/sgml/sc34/document/0299.htm#locator-reference >
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC