[sc34wg3] a new name for the Reference Model

25 Jan 2003 13:06:27 +0100

* Lars Marius Garshol
|
| The people on tmcl-wg are about to start work on a description of
| what TMCL is going to be and also a requirements document. If you
| care about TMCL I think you should join that mailing list to
| participate in that work. This discussion is about the TMCL
| requirements, so I do think you should make your views known as part
| of the process.

* Michel Biezunski
| 
| I'll do, but again now what matters first to me is how the pieces
| fit together.

Sure, but that's part of the requirements. An important part of the
requirements work is establishing the desired relationship to other
standards. The TMQL requirements document has a whole section on that,
and I believe the TMCL should have the same.

| My point about TMCL is in which sense does it define an application?

I don't think it does. I think it defines constraints on a class of
topic maps. That tends to have a close connection to applications[1],
but need not have.

| Since the SAM is "an" application, or "the" standard application,
| then I am raising the issue of the role TMCL will play in the family
| of TM-related standards.  It's not purely an internal-TMCL issue.

Well, what do you think? 

My view is that TMCL should be specified in terms of the SAM and allow
users to constrain the topic characteristics their topics may have. It
should probably be centered around the notion of classes, and so look
quite like AsTMa! and OSL.

In other words, the concepts in TMCL should be topics, names,
occurrences, associations, association roles, scope, types, and
subclasses. That means the most sensible thing is to specify it on top
of the SAM.

I don't see any need for any relationship to the RM. The RM is an
analytical tool for understanding the models of knowledge
technologies; it won't actually have applications of its own that need
constraint languages. The applications are technologies in their own
right, which will have their own constraint languages.

* Lars Marius Garshol
|
| One major decision taken in Orlando was that TMCL would be specified
| in terms of the SAM. If you want to change that you really need to
| state so loud and clear. And please bear in mind that it will have
| to be built on top of either the RM or the SAM. There are no other
| choices.

* Michel Biezunski
|
| It's not either or. It can be both. What I hope is that eventually
| there will be a realization that there is no contradiction. I
| recognize that you are uncomfortable with this view now, and it's
| possible that in order to fix this problem we should discuss a new
| rewriting of the RM.

I'm not "uncomfortable" with specifying TMCL on top of the RM. My
position is that either the language is specified in SAM terms, or it
is specified in RM terms. I just don't believe that it is sensible, or
even possible if you want a reasonable result, to do both at the same
time.

Either you are creating a language where you can say things like
"topics of type composer must have an association of type born-in
[blahblah about role types etc]" or "email occurrences are unique",
*or* you are creating a language where you say "nodes with assertion X
to nodes with SIDP value Y must have an assertion Z to ...".

As you can see, the kind of things you are saying in the two languages
are different, and so we are actually talking about two different
languages. There is TMCL (specified on the SAM) and there is RMCL
(specified on the RM). I don't see what we need RMCL for.

| I also know there are concerns with the way the SAM is currently
| formulated, [...]

Whose concerns are these, and what are they? I am trying to finish
this thing, so if there are any concerns they should be brought
forward *now*, not when it's too late.

* Lars Marius Garshol
|
| BTW, I'm surprised that you focus on TMCL the way you do. Isn't TMQL
| equally important, and doesn't it have much the same issues?

* Michel Biezunski
|
| My impression is that TMQL is how to *use* topic map applications,
| it doesn't say what they actually *are*. TMCL on the contrary seem
| to me to define the boundary of an application (validity, etc.).

I agree. But even so it is a question whether TMQL is going to query
SAM instances or RM instances. I think SAM instances, but it would be
good to know what you think.

| It's possible that your question might lead to realize that the
| boundary between TMCL and TMQL may not be as clear as we think it
| is. This is another thing that needs to be explored and clarified.

It's already clear that there is a relationship between the two. For
example, TMQL may make use of data types defined in TMCL, and TMCL may
have constraints defined using TMQL.

* Lars Marius Garshol
|
| I don't really understand why a 1%/99% (RM/app) division of
| constraints makes sense. The application will have to specify the
| bulk of the conformance requirements anyway, so why not everything?
| It doesn't really make sense to require people to read two specs,
| does it?

* Michel Biezunski
|
| Remember the standard is not only aimed at implementers, it's also
| for information users. The conformance clauses therefore are
| different, depending what the focus is. The RM insists on the
| subject uniqueness and it looks to me this is central to all topic
| maps conforming applications (whatever application means). This
| seems to me as a good candidate for a building block for the
| different necessary conformance clauses. What do you think?

I see it rather differently. If the RM really is only an analytical
tool for understanding how knowledge models work and how they relate
to one another I don't see a need for any conformance clause at all.
A conformance clause implies that there will either be data sets (be
it documents or databases) or implementations that follow the model.

Having a conformance clause that essentially applies to other
specifications rather than to data/implementations does not really
make much sense, I think. Those other specification will need to make
sure that they themselves provide the right conformance criteria and
will not reference the RM for additional conformance constraints. 

And in any case you can tune conformance by tuning the mapping from
technology X to the RM, so it's not really clear that the conformance
constraints can really accomplish anything anyway.

Does this make sense to you? Does this match what the RM people are
thinking at all?

* Lars Marius Garshol
|
| I'm glad to hear you say that you think the XTM model is all you are
| ever likely to need. I feel the same way. I do find your mention of
| user requirements not met by the SAM/XTM model disturbing, so I
| would *very* much like to hear what they are. We are supposed to
| finish it soon, so it would be good to hear them before it's too
| late.

* Michel Biezunski
|
| Let's try this, waiting for others to supplement this. 

Try what? This wasn't user requirements on the SAM. Do you have any?
If so, I would *still* like to hear them. You were talking about
justifying the existence of the RM, which is something else entirely.

| What if one considers the SAM as the user of the RM? If the
| requirements for interchangeability, interoperability, etc., that
| the SAM is supposed to fulfill are more easily handled by the RM
| which will make explicit what's happening under the cover (what gets
| reified, what are the assertion types, what gets merged, etc.), then
| it's enough to justify its existence.

I don't think the RM does any of this any better than the SAM does.
If you think there are questions the SAM does not answer that it
should answer (whether or not the RM answers them) I would like to
hear what they are.

| Again, this doesn't necessarily impact the technologies built over
| the SAM. It impacts -- only -- the SAM itself, i.e. the standard
| application. It means that existing products should not be directly
| impacted by the existence of the RM, [...]

This is how I feel as well, and that is why N0278 looks the way it
does. I'm now hearing noises that indicate that some people want to
change this, but it would be nice if they could get more specific.
*How* do they want to change it? *Why* do they want this?

| OK. As I said, my main problem for now is to make the pieces work
| together. When we'll all feel more comfortable about how this works
| --and I hope it's going to be very soon-- I am hoping that all
| contributions will be resented as positive rather than disturbing.

I understand this, but my position is that I was happy with the
roadmap in N0278 and see no need for any changes. If other people do I
would like to hear what their feelings are. All I have heard so far is
"we should discuss X" and "we should discuss Y", but that's not very
helpful. 

If we are going to finish this debate and agree on a new roadmap any
time soon we need to get actual input from the people who want the
roadmap to change in some way.

| [conformance in 13250 & XTM]
|
| Documents: it is a question of conformance to a DTD or architectural
| form.

That's how 13250 and XTM specified it, but it is not enough. There are
many more constraints on documents that are necessary. The SAM
constraint "Single reified" is one example of this.

| Applications: there was not much about it. (Kind of on purpose, but
| obviously insufficient now that real applications exist).

Good that we agree on that. There's also the issue of generic
13250/XTM implementations. There was very little guidance on what they
were supposed to do, so that was equally insufficient.

[1] Natural language sense, not RM sense.

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