[sc34wg3] a new name for the Reference Model

[Michel Biezunski]

> * Michel Biezunski
> |
> | 99% should be left to the application. The remaining 1% which might
> | result in creating some really pathological topic maps that will
> | look OK to a parser but would actually behave so ridiculously that
> | they would end up being unusable should be detected.
>

* Lars Marius Garshol:

> But shouldn't it be up to the application to detect that? The
> application will have to have its own rules for what is and isn't
> allowed anyway, so it might as well provide *all* the rules. Or?

We want a standard that is application-independent, while leaving
application implementers free to develop the kind of applications they
want -- until a certain point. It's kind of a self-contradictory statement,
but that's what we're trying to accomplish. We need to find the proper
limit.
There are some rules beyond which we can establish what is topic mapped
and what is not. These rules exist. My understand of what the RM is for
is precisely to enable us to see where the limit is. Let's use them since
they are
available, or at least assess them and reject them after having
analyzed why they don't fit. But I don't want to reject them a priori
just as a principle that you seem to follow that everything which
has to do with the RM should be discarded.

Complexity is part of the equation. Knowledge resists to simplification.
If we want to capture knowledge modeling, we'd better have a tool which
enables us to do that. It's different from creating a programming
language.


> Either TMCL is specified in terms of the SAM, or it is specified in
> terms of the RM. Doing both makes absolutely no sense, as far as I can
> see. We decided in Orlando that the basis was supposed to be the SAM,
> and so far nobody's expressed a desire to have it be otherwise.

The SAM and the RM are *NOT CONTRADICTORY*. They supplement
each other. Each of them needs the other, is enriched by the
other, doesn't make sense without the other. Everything in TM
has to be consistent from a high-level point of view and from
a low-level point of view. If we lose this ability, we are
heading for a short-term only, quick and dirty, XML-exclusive application
that will be fashionable for a few months before being replaced
by something even simpler, more straightforward, and more directly
compliant with the market leader practices.

Consequently, it's not because TMCL should be built on the SAM that it
shouldn't be built also on the RM.

> If you care about TMCL I suggest you join tmcl-wg on YahooGroups and
> make your views known there. The editor is about to issue a call for
> requirements, so this would be the time to make your views on what
> TMCL should be known.

I am trying to make things hold together and understand how
the various pieces articulate with each other. I think it's
critically important that each of us, especially those like
you who are responsible for a portion of the standard, understand
fully what the others are doing. If every subgroup has its own
dynamic, we'll end up very quickly like W3C XML related standards
where nobody knows what others are doing, and they overlap and
contradict each other all the time.

> | Because thanks to the RM, it becomes possible to regard other
> | applications than those strictly conforming to SAM be TM
> | applications as well.
>
> OK, but what does that mean in practice? The more you talk about the
> RM, the less it sounds like a purely analytical tool, and the more it
> sounds like a competing technology. (I've accepted that long ago, but
> I do wish the RM proponents would be clearer about what they think the
> RM is.)

A technology competing with what? The RM is aimed to provide the
foundations for understanding what's going on with topic maps under
the cover, to make explicit things which are implicit.

Yes, the RM allows potential other applications than SAM to be regarded
as Topic Maps. Is that the problem you are trying to address? Why would
this be a bad thing?

> | However, I have heard people claiming that they need applications
> | not covered by the SAM and I don't see why they shouldn't be able to
> | accommodate their needs. We just need to understand more precisely
> | what they are.
>
> Can you provide examples? If this is real it should be put on the
> table so we can assess it and consider what to do.

I'll let that to those who have made such claims. If you read this
and recognize yourself, please answer to that. It would help everyone
to understand better.

> XTM 1.0 compared with SAM and SC34 N0328 is one example of the
> difference. They specify exactly the same thing, but XTM 1.0 doesn't
> answer half the questions it should, and is TR-like (though it does
> have some substance to it beyond what a TR would have), while the
> other two really do define what must be defined.

The "authorative text" for topic maps is the text of ISO 13250.
This is the one that should serve as a basis because this is the
one that is used now as a standard. One of the reasons why we didn't
incorporate the text of XTM 1.0 directly into the ISO process is
for the reasons you said. So why create a problem where there is not?

> | I like the idea that some of the things are still "experimental" and
> | need technical study before we can "legislate" what goes in the
> | standard and what not. This is particularly important when deciding
> | what is a conforming application. We don't want to standardize too
> | early (ie. something that later will prove not-standardizable!). The
> | idea of distinguishing where is the limit between what we are
> | actually sure of (and should go in the standard) and what is there
> | to be tried, is a good one.
>
> That's something completely different, I think. Topic maps have been
> in flux for over a decade now. It's time to nail something down and
> have a first proper specification.

ISO 13250 is an approved international since 3 years. It's because
there is an ISO standard out there that there is a market.
It's kind of strange to have to say this here. Hello, Lars, where
have you been?

> Can you give me an example of an application area covered by the RM,
> but not by the SAM?

The SAM itself, considered an application.

> And if the RM is really just an analytical tool I don't see how it
> could matter even if it *did* cover more application areas, since it
> wouldn't then be a technology that could be applied to them.

We are not limiting ourselves to standardizing "technologies" in the sense
you describe. We are dealing with a standard for information management,
and this has several aspects. In other words, it's much broader
than an API or a guideline to build software.

> * Michel Biezunski
> |
> | No, I disagree. We have not said that HyTm was not usable.
>
> No, we haven't, but the fact is that none of the implementations were
> interoperable. Exporting a topic map from one implementation and
> importing it into another just wasn't possible, because the
> implementations were using different DTDs. So while it certainly
> wasn't useless it definitely wasn't interoperabe.

Not true. If the different DTDs are referring to the proper
standard-defined architectural forms, then HyTm applications are
interoperable. Interoperable doesn't mean necessarily being stuck
to one DTD. That's the choice we did for XTM. But it doesn't invalidate
HyTm interoperability.

> That's because nobody's really using HyTM. Ontopia has implemented
> both, and I can tell you that there are a lot of issues besides just
> facets, for those who actually want to implement both. We basically
> wound up making a lot of implementation choices in the areas not
> covered by the existing specifications.

I would think it would be very valuable to have this list of
issues published, because even if HyTm is not actually used,
it would help us understand where is the boundary between an
application and a standard application and fix the problems
that may remain for the SAM. Are you willing to publish those?

> Yes, Michel. I'm trying to explain to you why your statement that
> topic maps have been stable is false. The specifications we have now
> are not very precise, but it's obvious that XTM presents major changes
> compared to HyTM, and it's equally obvious that we have not yet
> finished creating proper specifications for the two. That's not a
> situation you can call stable. The work wasn't even finished, so there
> wasn't anything there that *could* be stable.

It's fairly stable as far as document owners are concerned. It's
a fact that there are some variations in the interpretation of
some concepts that need to be clarified, but that's rather a good
problem to have because it means that now we can base ourselves, we
have a lore which has been accumulated since the standard has been
published. Having to make things explicit and clarify certain points
is a good thing. I am not complaining about the work we're doing.
I just don't think it's horrible. I think it's normal to have to
do that.

> Absolutely, but ISO 13250:2000 and XTM 1.0 were not specifications
> that could support interoperable implementations. And even if they had
> been XTM 1.0 introduced new things which did more than just extend.

Well, yes, the difference between subject indicator and subject constitutor
to list one. OK, let's work on fixing it.

>
> | [...] and figuring out exactly what the SAM is supposed to be.
>
> Don't you know? If so, please tell me what you are uncertain about,
> and I'll do my best to help clear it up. It's supposed to be finished
> soon, so we'd better agree on what it is soon.

I am interested not by the SAM, not by the RM, not by TMCL as such, I am
interested to know what Topic Maps are for, where they apply, who should
use them, this kind of things. Some of the things you said make me
think that we still not have the big picture in place and certainly
the various pieces do not fit harmoniously together. Getting this
straightened up
looks to me like the first priority and what I want to see happening is an
agreement on what is the role played by the SAM in the big picture.


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