[sc34wg3] a new name for the Reference Model
Michel Biezunski
sc34wg3@isotopicmaps.org
Sat, 4 Jan 2003 07:46:12 -0500
* Steve N:
> (2) Topic Map(s?) Models, including but not limited
> to the Standard Model, govern the topic map
> documents and enabling software that claim
> conformance to them. When a Topic Map(s?)
> Model inherits ("borrows", includes) another
> Topic Map(s?) Model, the inherited Model *also*
> governs the documents and software that claims
> conformance to the inheriting Model.
There are 2 levels that need to be distinguished here:
- 1) the SAM model or another model
- 2) a set of constraints for a given topic map application
as defined by the yet-to-come TMCL language.
For the sake of clarity of this discussion, I propose
to temporarily call the first a "model" and the second
a "schema".
The limit between model and schema has not yet been discussed.
For example, does the specification of merging rules belong
to "model" or "schema"?
* Steve N:
> We should decide what we want to do about this. I
> think there are several choices, including:
>
> (1) We do nothing. We don't say anything about it.
> We pretend the issue doesn't exist, and we face
> it at some later date. (I think this is the
> worst possible choice. It weakens both the SAM
> and our credibility. It creates a situation in
> which weeds will thrive.)
We could have done that if we would have decided that the
name-based merging rule was OK the way it was. We seem to
go in the direction that the merging rule based on name
should be discarded, because scopes are overloaded.
>
> (2) We say that user-defined assertion types in
> XTM/HyTM *are not* allowed to have any
> semantics such that the subjects of any of
> their role players are specified by instances
> of such user-defined assertion types.
>
> If we choose this option, whenever a topic map
> author wants topics to be merged, he must say
> so explicitly and redundantly, either with a
> <topicRef> or with two <subjectIndicatorRef>s
> to the same subject indicator. Michel likes
> this idea. It protects developers of XTM/HyTM
> processors from ever having to support
> user-extensible merging rules, and it may have
> other advantages of which I am not yet aware.
Let me comment why I favor this option (that Steve and
I discussed during a phone conversation). It means to me
that the interchangeable form of a topic map, as expressed
with an XML/SGML syntax, already contains the information
necessary to merge as part of the address of the subject
identity. Everything that topic map authors intend to see
merging is expressed there, unambiguously, within the existing
syntaxes. If somebody wants to use the name-based syntax using
scopes it's still possible to do without this rule being present
in the standard, by creating the necessary addresses resulting
from the combination of scopes/names. This is part of the
authoring process of a topic map. If another application wants
to merge names by string, it's possible to populate the subject
identity to do exactly that. This preserves the existing XTM
applications, preserves the ability of users of saying what
they need to say.
> I dislike it because I think it should be
> enough to say, in domain-specific terms (i.e.,
> via instances of user-defined association
> types), that topic A has subject S1, and topic
> B has subject S1, and expect that A will merge
> with B simply because they both have the same
> subject. It shouldn't *also* be necessary
> to say explicitly:
>
> (i) that topic A also has subject indicator
> SI1, and topic B also has subject
> indicator SI1, or
>
> (ii) that topic A has the same subject as
> topic B.
I prefer simplicity and redundancy over shortcut that
impose to the application to do many things that are not
implicit. I know we can't achieve this completely. But the
more we stick to this principle, the more we avoid the XML
implementers of topic maps to believe they are implementing
topic maps whereas in fact they are not.
>
> If the SAM imposes a requirement to supply such
> redundant information in each topic map, we
> will eventually have to answer the following
> embarrassing question, emanating from possibly
> irate users: "Why does XTM/HyTM allow
> user-defined association types at all, since
> they aren't allowed to mean anything in terms
> of subject recognition?"
We don't need to do that if we split the merging rules and
subject recognition from the association types. I believe that
there is a big difference between an association (as defined
by SAM) and an assertion (as defined by RM). I disagree with
the way Steve is assimilating them.
> (3) We say that user-defined assertion types in
> XTM/HyTM *are* allowed to have semantics such
> that the subjects of their role players are
> specified by instances of such user-defined
> assertion types. We require that, when such
> topic maps are interchanged, they must include
> the information necessary to allow such
> subjects to be merged automatically, in the
> normal course of topic map processing, whenever
> such subjects are identical.
>
> Personally, I strongly favor this third choice.
> It doesn't require us to delay the
> standardization of the SAM, even though we may
> wish to add stuff to the SAM, at some future
> date, that *standardizes the expression* of the
> additional TM Modeling information necessary to
> extend the merging rules of XTM/HyTM in support
> of domain-specific subjects. It leaves
> XTM/HyTM's future indefinitely long and
> indefinitely bright -- as long and bright as
> the full breadth and depth of the TM paradigm
> itself. It won't force XTM users to learn how
> to make TM Models; it only leaves open the
> possibility that they can use such knowledge if
> they want to, without first having to abandon
> XTM.
But it makes it very hard to explain to implementers how
to successfully implement topic maps. That's really a huge
obstacle for me to this solution.
> In any case, we really need to face this issue.
>
> > Does [the RM] specify or interpret?
>
> It specifies. If it only interprets, then its
> constraints are optional, and we abandon the idea
> that "Topic Maps" means reliable, predictable,
> ontology-neutral knowledge aggregation.
Reliable and predictable will still work. Ontology-neutral
depends what you call ontology. If you call SAM an ontology,
then it won't. If you call ontology a topic map schema or
application as defined by a user using SAM, then it will still
be ontology-neutral.
I believe that the RM neither specifies nor interprets. For
me, the RM provides the foundations. Once it's there, it can
become transparent. RM within SAM should be a black box. Once
SAM is properly constructed, we shouldn't need to see the RM
any more, but we'll know it's there. It's like when you eat
an orange, you don't need to see the vitamin C. But it's good
to know it's there.
* Steve N:
> The RM and SAM are both deeply technical. The
> answer to the question, "What does 13250 mean?" is
> not light reading. If if we pack both the SAM and
> the RM into 13250, along with HyTM and XTM, we'll
> have a big, heavy standard that nobody will read.
> (I hesitate to mention three examples of too-heavy
> standards: HyTime, STEP, and XML Schemas. All
> three are marketing disasters, despite whatever
> technical virtues they may or may not have. The
> primary problem with all of them is that they are
> TOO BIG.)
Not good enough. Even if the RM and the SAM are deeply
technical, they should be written in a way that makes
them not only appealing, but crystal-clear, easy to
learn and implement, unambiguous. If we don't make
a commitment to do everything we can to provide with
the clearest, simplest, easiest, most obvious text(s)
we can, the work we are putting in is going to be lost
because not enough people is going to use this standard.
I agree with the multiple standards schema (I was the
one who originally proposed this) but this doesn't mean
that we could allow ourselves to have very obscure
text hidden in the parts which are more remote.
> We need Topic Maps to be *perceived* as light,
> easy, and intuitive. The XTM DTD gives this
> impression. Great!
Again, we have to go beyond the "perception". TMs
should be light, easy and intuitive. If they're not,
something else which will be lighter, easier, and
more intuitive will be used instead.
This looks obvious, but it's not. It's more difficult
to reach simplicity than complexity. Especially because
we want, and we need, to preserve the complexity of
the knowledge that is encoded using topic maps.
> So, if we go the multipart route, I want to be
> very, very certain that the default, leading ISO
> publication on Topic Maps is very short and sweet,
> has the XTM DTD in it, and damn little else. It
> should be a "README" for Topic Maps.
We have to decide whether we want to preserve the HyTM
meta-DTD or not. There are many advantages to put it
apart (nobody seems to be using or implementing it any more,
it doesn't have the distinction between subject indicator
and subject constitutor, it creates lots of extra work
for no visible advantage in terms of the market).
There are also some drawbacks (are we still going to be
credible when we'll say that we are going to provide
with backward compatibility, etc.)
My proposal is to have a README for topic maps, with
no syntax in it, and cross-references to line numbers to
both the XTM and the HyTM DTD which would be 2 annexes.
===================================
Michel Biezunski
Coolheads Consulting
402 85th Street #5C
Brooklyn, New York 11209
Email:mb@coolheads.com
Web :http://www.coolheads.com
Voice: (718) 921-0901
==================================