TMCL requirements; Was: [sc34wg3] a new name for the RM

[Mary Nishikawa]

At 13:06 03/01/25 +0100, Lars Marius Garshol wrote:

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

We look forward to your comments here, Michel.


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

I noted this. Yes, it is necessary. The relationships between other 
standards  is the reason for all of the inquiries I made to the tmcl-wg 
list so far.

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

I don't even see it this way, since I do not think a "class of topic maps " 
is the best way to put it and is not easily defined. The SAM describes what 
a TM is, especially for business applications in the real world. I think 
that we will need to define the constraints that would naturally follow 
the SAM  and would help developers  create software that would make 
ontology building easier for KM architects/taxonomists.

The RM is a conceptual model for graph model theorists. We need it and 
them. I think that somebody could write constraint rules (as a model) for 
RM. It would be a very difficult and interesting thesis project. I do not 
see it in the realm of business applications. If it is, somebody please show me.

Most of the constrainting that I am doing now, is in my head (mind as 
parser- I am deciding what I should or should not do based on rules that I 
have learned from LMG, SP, BV, TB, TP  among others. -- I think that we 
should get them down on paper :)

I say what I am thinking here, and if it is wrong, I stand corrected.


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

agreed.


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

agreed.

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

This is interesting! More great thesis projects for somebody (and I really 
mean this).


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

Thanks for this information. I was not aware of this decision. So the 
direction we are going in seems to have been thought about already; encouraging!

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

I cannot comment on this. I thought that the RM was the conceptual model 
above the SAM. This sounds like something else now.

>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 have heard from many enthusiastic developers who really want to help 
their customers. I think that the ISO standardization process is for them. 
I t would be good for us to find out what is needed by this community. This 
is one of the reasons why I got involved. I have not heard requests to have 
a TMCL based on the RM.

Michel If you know of anyone, they should join tmcl-wg and give feedback.

---cut---

>
>* Michel Biezunski
>|
>| Remember the standard is not only aimed at implementers, it's also
>| for information users.

---cut---

I really disagree with this statement. These standards are not for 
information users. We do need documents for them too, but the RM, SAM, 
TMCL, TMQL are not for them. We do need a good tutorial-like introduction 
though and something equivalent to Tom Bray's annotation of the XML 
standard (note: this was not part of the standard, but possibly read by 
1000X more people than the original standard itself) The standard was read 
by the parser writers (I hope :))

---cut---


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

Ageed. I wish we can settle this and keep the roadmap. There are too many 
documents dependent on it now. Changing this means updating  a number of 
others. We really can't leave this open and change it every time we meet 
face to face. If this was agreed to in Orlando, we should stick with it and 
besides that, it is organized and makes sense to everyone, I think :))

Cheers,
Mary

***********************************
Mary Nishikawa,  EDMS Technical Advisor

Schlumberger K. K.
2-2-1 Fuchinobe
Sagamihara, Kanagawa 229-0006
Tel:  +81-42-759-5376
Fax: +81-42-759-3563
************************************