[sc34wg3] a new name for the RM

[Mason, James David (MXM)]

I'm going back to the original thread.

My point is that if we do modelling, we need to have concrete, specific
goals, and we need to get them established soon.

If we don't have such goals, then no matter how fine our theoretical basis
is, we're wasting our time.

Now we probably do need a good theoretical basis, not to prove how good our
academic computing credentials are (which is all the ODA people eventually
got) but rather so that we can do some things we need:

*	So we know what we're doing when we say we want to merge x and y
*	So we can make sense of whether some component of a topic is better
done as an occurrence or a variant on a name
*	So we know how many things really need to be reified
*	So we know whether we're boxing ourselves in when we try to do the
CL and QL
*	So we can talk intelligently with other communities with which we
need to cooperate (e.g., RDF, SUO)
*	So we can write better tutorials

That list starts in standards territory. It ends closer to TR territory.
Which territory we wind up in depends on what we think our audience is and
what we set as our goals.
 
The goals for which JTC1 chartered SC34 do not include making ourselves
academically respectible or teaching users how to get the most out of their
information.. Our duty is to both end users and implementers, but primarily
to implementers. We are to interpret the needs of end users and then
instruct the implementers, through standards, how best to meet the users'
needs. 
 
Explaining to the users how we went about this is only minimally part of our
charter. Without the users, we have no justification for having a committee,
but training the users is more a function for IDEAlliance conferences and
publications in the open literature than it is something we have to do
inside SC34 and its publications.
 
I'm not a fan of doing TRs. We did TR 9573 (Techniques for using SGML)
because we weren't getting some things published elsewhere. Eventually the
publishing market (and UNICODE and XML) overtook us, and we stopped adding
to that thing. We should do TRs only if we can't get our message out by
other means. 
 
Jim




-----Original Message-----
From: Lars Marius Garshol [ mailto:larsga@garshol.priv.no
<mailto:larsga@garshol.priv.no> ]
Sent: Monday, January 27, 2003 3:08 PM
To: sc34wg3@isotopicmaps.org
Subject: Re: TMCL requirements; Was: [sc34wg3] a new name for the RM



| 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
<http://www.ontopia.net>  >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no
<http://www.garshol.priv.no>  >

_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
<http://www.isotopicmaps.org/mailman/listinfo/sc34wg3>