[sc34wg3] a new name for the RM

[Michel Biezunski]

Jim and al.,

> My point is that if we do modelling, we need to have concrete, specific
> goals, and we need to get them established soon.

Yes, the goal I propose is to build a solid foundation for the
topic map standard and its satellites.

> If we don't have such goals, then no matter how fine our theoretical basis
> is, we're wasting our time.
>
> Now we probably do need a good theoretical basis, not to prove
> how good our
> academic computing credentials are (which is all the ODA people eventually
> got) but rather so that we can do some things we need:
>
> *	So we know what we're doing when we say we want to merge x and y
> *	So we can make sense of whether some component of a topic is better
> done as an occurrence or a variant on a name
> *	So we know how many things really need to be reified
> *	So we know whether we're boxing ourselves in when we try to do the
> CL and QL
> *	So we can talk intelligently with other communities with which we
> need to cooperate (e.g., RDF, SUO)
> *	So we can write better tutorials

Yes to all.

> That list starts in standards territory. It ends closer to TR territory.
> Which territory we wind up in depends on what we think our audience is and
> what we set as our goals.
>
> The goals for which JTC1 chartered SC34 do not include making ourselves
> academically respectible or teaching users how to get the most
> out of their
> information.. Our duty is to both end users and implementers, but
> primarily
> to implementers. We are to interpret the needs of end users and then
> instruct the implementers, through standards, how best to meet the users'
> needs.

Yes, I agree. Aiming at implementers means that we need
to enounce clearly what are the building blocks that are used for
designing information and software products, and that the information
products that are built by software company A are going to be able
to be operated with tools built by software company B. This doesn't
mean that all features in A have to be present in B.

It looks to me that the way the standard development is currently
structured is not necessarily fulfilling this objective.

What we currently call the SAM covers 2 things:

1) The topic map model, brillantly marketed as TAO, which is built on
the principle of uniqueness of subject per topic. This is the core
of Topic maps. And even if some aspects still need to be clarified,
it is the stable basis of which the standard exists and is known.

2) A decomposition of this model in an API-like manner, in a form
that can be used as a basis for building products and assessing their
conformance.

What we currently call the Reference Model covers 2 things:

1) An assertion-centric theoretical model stating the foundations
on which topic maps are built.

2) A topic map graph model, which is a decomposition of how an
application sees the result of topic map processing. (At least
that's the way I understand it).

It seems to me that we should reorganize our plan by grouping the
two 1) together and the two 2) together. This would have the effect
of giving us:

- a stronger "topic map model" based on the concepts of
TAO, scope, subject uniqueness. This model should import the
current model as in 13250, clarify all the points that remain obscure
and that have proven obstacles to application interoperability
(scope for example).

- an implementation guideline, that would cover the list of objects
and their properties (currently called SAM) and a graph-decomposition
that would basically establish what a topic map "parser" would see
and make sure that the result of one application using product A is
identical to the result of the same application using product B.

The description of these 2 sets needs to be refined, but this
is a rough draft of how I see us making progress for the future
steps.

Therefore, I propose to stop dividing the development into
SAM and RM and start considering a more integrated approach by
clearly dividing the tasks and have everybody get on board and
enriching everybody else with their own findings, rather than
continuing to develop "competing" sub-approaches that don't do
anything to improve the state of the standard, and on the contrary
that have damaging side-effects, one of them being a lot of energy
wasted in endless fruitless discussions. In other words, the SAM
and RM teams should get together and improve each other's
concepts and visions. And I think this is a good moment for this
to happen. We have the texts now which have been provided, we know
what each team is up to, let's start the integration.


In another mail you (Jim) wrote:

>We do need to guard, however, against the RM becoming too theoretical. Back
>in the old days of the ODA/SGML War, I used to needle the ODA guys because
>they didn't define anything with a production grammar (like SGML), BNF, or
>any other quasi-mathematical formalism. Eentually they decided to outdo the
>SGML folks by starting a "Formal Definition of ODA". It turned out to be a
>great tree-killer, volume after volume of symbolic-logic notation that
>amounted to an existence proof for ODA. Absolutely no use to anyone, either
>users or implementers. It kept them occupied. It also kept them from doing
>any useful work, and that helped lead to the cancellation of their project.
>Mission accomplished!

ODA had another feature. It was based on a single DTD. That's what we
have with XTM. However, the major difference is that despite the fact
that XTM is a single fixed DTD, it leaves completely open the possibility
for users to define their own topic map applications (types, association
semantics, etc.). ODA because it was based on a single DTD hoped to be
able to define what products were going to look like (word processors, etc.)
and that's what killed it also.

We should be careful to avoid falling in a similar trap. It's not because
we have a fixed DTD with XTM that it means that we have to define
applications
in a way which is so restrictive that it won't let creativity flourish and
it won't be amenable to unheard-of, innovative, technological developments
that aim at addressing the very same issues that we are dealing with. That's
what concerns me the most with the way the SAM is currently designed as a
set of API-like features that may have the effect of limiting tremendously
the applicability of the standard, especially with the forthcoming TMCL and
TMQL which might further limit the extension of the standard, if they are
not based on the proper level of abstraction.

This is why I am advocating for merging completely, in a way which will
make their origin indistinguishable, the works that are currently being
done under the label SAM and under the label RM. Let's consider both the
SAM and the RM both together as necessary scaffoldings that have led us
to the point that we understand better what we are doing. Let's
stop developing them as such and extract from both sides what's necessary
to build the strong topic maps standard that all of us need.

Michel
===================================
Michel Biezunski
Coolheads Consulting
402 85th Street #5C
Brooklyn, New York 11209
Email:mb@coolheads.com
Web  :http://www.coolheads.com
Voice: (718) 921-0901
==================================








>
>
> -----Original Message-----
> From: Lars Marius Garshol [ mailto:larsga@garshol.priv.no
> <mailto:larsga@garshol.priv.no> ]
> Sent: Monday, January 27, 2003 3:08 PM
> To: sc34wg3@isotopicmaps.org
> Subject: Re: TMCL requirements; Was: [sc34wg3] a new name for the RM
>
>
>
> | We do need to guard, however, against the RM becoming too
> | theoretical.  Back in the old days of the ODA/SGML War, I used to
> | needle the ODA guys because they didn't define anything with a
> | production grammar (like SGML), BNF, or any other quasi-mathematical
> | formalism. Eentually they decided to outdo the SGML folks by
> | starting a "Formal Definition of ODA". It turned out to be a great
> | tree-killer, volume after volume of symbolic-logic notation that
> | amounted to an existence proof for ODA. Absolutely no use to anyone,
> | either users or implementers. It kept them occupied. It also kept
> | them from doing any useful work, and that helped lead to the
> | cancellation of their project.  Mission accomplished!
>
> I think your story is actually making a different point: we need to
> guard against becoming forever stuck at the model level. At the moment
> we have one group of people who want to continue working on the
> conceptual foundation, and we have another group of people who want to
> continue working towards providing the features (QL, CL, ...) that
> people will need to actually use this.
>
> That doesn't need to be a problem, so long as those two groups can
> come to a common understanding about where and how their efforts
> interface. I believe we can do this, but it does require us to
> actually have a debate about it.
>
> --
> Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net
> <http://www.ontopia.net>  >
> GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no
> <http://www.garshol.priv.no>  >
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
> <http://www.isotopicmaps.org/mailman/listinfo/sc34wg3>
>
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>