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

[Lars Marius Garshol]

* James David Mason
| 
| We're talking about two audiences here: implementers and users. (At
| the moment, those audiences overlap heavily, but if our standards
| succeed, they will incresingly become separate, as has happened with
| SGML/XML.)
| 
| My view is that we write standards primarily for implementers; we
| write TRs primarily for users.

I very much agree.
 
| If the RM is about a base-level definition of what TMs are, then it
| sounds like a standard. It ought to be, as Martin says, "human
| parsable" (I find the current 13250 pretty opaque). It ought to go
| from graph theory, or some other suitable starting points, to the
| point at which we can build the SAM.
| 
| If we want to say what all this means for people building
| ontologies, etc., then that ought to be a separate document, a TR. I
| strongly support having a TR, maybe more than one TR, to help users
| like me who can't make it through the thorny stuff!

You have put your finger on it, Jim. I have yet to see a clear answer
from the RM group on which of these two things they think the RM is. I
think it is imperative that we settle this issue soon, so that we can
move on.
 
| 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 >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >