[sc34wg3] a new name for the Reference Model

24 Jan 2003 17:29:42 +0100

* Lars Marius Garshol
| 
| If that is truly how it is intended to be used I agree. The question
| is whether that is the case. If it is, for example, why does it need
| a conformance seection? It talks about conforming applications (like
| SAM), implementations, and data sets. Why isn't all this just left
| to the applications?

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

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?

| [RM-TMCL relationship]
|
| Yes, I see what you mean. As far as I know, there has not been any
| decision made about what TMCL is and what it contains. 

The decisions that have been made so far are recorded in SC34 N0226
and N0278.

| What you propose and what I propose is different, albeit
| complementary. I don't see why you and I couldn't get what we
| describe, even if it's different.

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.

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.

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

| I agree with you that the model brought by XTM is wide enough to
| accommodate a huge number of information models. As far as I am
| concerned, it looks like this is all what I would ever need to work
| on for my customers based applications (although it's difficult to
| be sure about this). 

In that case we are on the same page. This is how I see it as well.

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

* Lars Marius Garshol
|
| Sure, but the RM is no closer to the SAM than RDF is. SRN himself
| has said that creating a SAM<->RM mapping is a tricky thing to do. I
| think that speaks for itself.

* Michel Biezunski
|
| No it doesn't. I have no idea why it is tricky unless I know more.
| Why? What? How? (not who?)

Well, SRN just sent me an email offlist which showed exactly what
difficulties he had run into. If he could post that to the list, or
forward it to you I think you would understand. (I won't do that
myself, as I assume SRN had some reason for doing this offlist.)

* Lars Marius Garshol
|
| Yes, but even so we must ensure interoperability, and the only way
| to do that is to put strict and well-defined requirements on
| implementations and instances. Either that, or we should be
| publishing technical reports.

* Michel Biezunski
|
| I am not sure exactly what you mean by that difference. 

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.

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

* Lars Marius Garshol
|
| How is the RM model any more independent of application area than
| the SAM is?

* Michel Biezunski
|
| Because it's more low-level. As you said before, RM is more like
| Ascii whereas SAM is more like XML. There are plenty of things in
| Ascii that are not in XML (and that even are not considered
| applications).

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

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.

* Lars Marius Garshol
|
| As a technical report, a general guideline for how to organize
| information it's been pretty stable. As a standard, something
| intended to guarantee the interoperability of data and
| implementations, it has simply been a mess.

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

| We are not preventing any one to continue using HyTm. The 2 syntaxes
| relate because they use the same concepts. The only problem I see is
| the one Martin pointed out: it's not obvious how to use facets with
| XTM. Apart from that, the rest is all there. It's not documented
| yet, but we haven't had a lot of complaints how to map one into the
| other.

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.

The fact is that although the people in the ISO committee have a
pretty good idea of how to do the mapping things are not nearly as
clear cut outside the committee, and you can't even expect that all of
us have the *same* idea of how to do it.

| By leaving the standard as it was and adding the XTM DTD, we have
| technically speaking not removed anything from it, we have
| supplemented it with something else. It's an extension, not a
| reduction.

It's a mess, from a technical point of view. For someone to sit down
and implement ISO 13250:2002 would be a horrible job, and it certainly
wouldn't be interoperable with other implementations.

| The "mess" you are describing is precisely what we are trying to fix
| now, with the SAM and the RM. 

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.

| There is no contradiction between the notion of stability and
| evolution. A standard can be stable and still evolve. It can be
| extended, made more precise, fixed, maintained, all this enters in
| the category of stability. On the other hand, a standard where
| everything can be changed by anyone new who enters the game is not a
| stable standard. The topic map model is pretty stable.  It doesn't
| mean it's absolutely perfectly defined in all respect.

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.

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

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >