[sc34wg3] SAM-issue term-scope-def

Lars Marius Garshol sc34wg3@isotopicmaps.org
25 Jun 2002 11:37:51 +0200

* Lars Marius Garshol
| That is just an assertion, though. Could you say *why* you think it
| would be a mistake?

* Martin Bryan
| I gave the reason in the following paragraph, but to reinforce it I
| would state that to have XTM use intersection while ISO13250 clearly
| states union suggests that the two standards are in competion. I
| thought the idea was to try to align them without changing the basic
| concepts.

ISO 13250:2000 clearly states "union", while XTM 1.0 clearly states
"undefined". The reason we are having this discussion is that there
are problems with both of those definitions. I tried to explain what I
thought those problems were in

  <URL: http://isotopicmaps.org/pipermail/sc34wg3/2002-June/000290.html >
  <URL: http://isotopicmaps.org/pipermail/sc34wg3/2002-June/000287.html > 

It may be that these explanations are unsatisfactory, in which case I
guess I should sit down and write up a more organized paper on this.
(If people feel I should do that, please let me know.)

| Marc's preferred option in his 7th June message is "the set of all
| topics", which I agree with as it matches the wording in ISO 13250.

Well, no, it does not. ISO 13250:2000 says "all topics in the topic
map," which is not the same as the set of all topics. That solution
will cause complications for the serialization recommendations, the
canonicalization syntax, and TMQL/TMCL. 

That is why I suggest that we use intersection instead, since the
unconstrained scope then naturally becomes the empty set, which is
free of all these problems.

* Lars Marius Garshol
| We could do that, but it would mean that
|  a) the unconstrained scope changes every time a new theme is added
|     to a scope, and
* Martin Bryan
| Yes, just as it would if you added a new topic and made that the
| scope of another topic. Are you saying that latter should be
| disallowed as well? 

No, what I am concerned about are the presence of side-effects within
topic maps. Let's say I have a topic map of 10,000 TAOs (that is, a
medium-sized one), wherein about 5,000 topic characteristics are in
the unconstrained scope. Now I add a new topic to the topic map,
which, I agree, is a perfectly natural thing to do, and next I add it
to the scope of some topic characteristic.

What happens then is that 5,000 scopes change, even if I didn't
explicitly touch any of them. That doesn't seem right to me. I haven't
reasoned out the consequences in detail, but it does smell. What
happens with scope indexes, for example? What happens with event
listeners in an API? And so on.

I'm not saying that this is necessarily anathema to me, but it seems
to create lots of potential problems, and I don't see that it solves
anything. So why should we want to choose it?
* Lars Marius Garshol
|  b) it would be subject to exactly the same problem that Marc
|     described.
| So I don't think that is a viable solution.
* Martin Bryan
| The problem is that the intersection of scopes approach causes loss
| of data, and that I do not like.

In what

| Marc's suggestion of using all topics is the correct one, but this
| may result in too heavy an overload for processing. My suggestion
| would provide a halfway house between the two extremes.

I don't think Marc's suggestion will cause an overhead that is
necessarily that much heavier than yours. The set of all topics can of
course not be stored explicitly, but that's not necessarily a problem.
The main problem is that it cannot be enumerated[1], which causes
difficulties in some situations.

| (Not that I expect anything I suggest to be used!)

That's strange. I've found your input very valuable so far. I don't
see any reason why we shouldn't use at least some of your suggestions,
but if you do then please tell me why. 

[1] Not in practice, and quite possibly not in theory either. It would
    surprise me if the set of all topics were countably infinite.

Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >