[sc34wg3] SAM-issue term-scope-def

[Lars Marius Garshol]

* Marc de Graauw
|=20
| The terminology is not a happy one. Intersection and union are
| things one does with sets. Scope is a set of topics, but when we say
| that a scope Finland, Norway is an intersection (or union) we are
| applying intersection (union) to the topics Finland and Norway, and
| those topics are not (necessarily) sets.

You are of course right about that.=20
=20
| The basic idea behind it is clear though. In some way a scoping
| topic applies within a certain context, and the topic characteristic
| assignment is valid when that scoping topic applies. So if we have
| topic X with name Y which is scoped by topic A, then Y is a valid
| name whenever A applies.

And about this.
=20
| When we refrase scope-as-union in this way we get: if we have topic
| X with name Y which is scoped by topics A and B, then Y is a valid
| name whenever A applies _or_ B applies
|=20
| When we refrase scope-as-intersection we get:
| if we have topic X with name Y which is scoped by topics A and B,
| then Y is a valid name whenever A applies _and_ B applies

And about this.
=20
| What 'applies' really means is not relevant, this is basically up to
| the application (or user) of the Topic Map. However, if an
| application wants to do something useful with scope it has to decide
| whether a scoping topic 'applies' or not - at least I can see not
| other way to do anything with scope.

And about this. I also you like your suggestion for rephrasing the
definition of scope.
=20
| Furthermore, I suggest the word 'only' should be dropped. When we
| say topic name 'economie' is valid in when the scoping topic 'Dutch'
| applies, we surely do not intend to say this name is valid _only_ in
| Dutch. What we assert is that it is valid in Dutch, and we do not
| really say anything about its validity outside this context. (In
| other words, it is quite possible that other languages use the same
| word for this topic.)

This I am much less convinced about. I fear that if we remove the
"only" we are weakning the definition to the point where there is no
real distinction between "and" and "or".

I also don't think you are really saying "economie" is only valid in
Dutch. What you are saying is that it is valid in Dutch. It may be
valid in other contexts, but you aren't saying anything about it, just
as the concept may have other names in Dutch, but you haven't said
anything about that either.

I think this is the old "that I haven't said it doesn't mean that it
isn't so"-issue.
=20
| I do not have very strong opinions on the all-subjects or
| any-subject views.  I surely agree that in the former case the
| unconstrained scope should be the empty set and in the latter one
| the set of all topics - or some similar construct, such as Martin
| proposes. For me, as a Topic Map author, either way would work.
| It seems the any-subject view is compatible with ISO13250 (but
| phrased better), and the all-subject view is easier implementable
| for Topic Map application vendors since it avoids the set of all
| topics.  I would tend to the any-subject view for backward
| compatibility if there is a reasonable way around the problems with
| the set of all topics (or similar contructs).

I think this sums up the current state of the issue quite neatly.

One thing should be added, however: the any-subjects (or "or") view
also causes problems for TMQL and its scope operators, and it is
likely to also have awkward implications for TMAPI[1]. Further, it
seems that the any-subjects/"or" view implies that the current merging
rules should be changed as well.

It is beginning to look as if this issue is sufficiently complex that
it deserves a write-up in the form of an informal paper that outlines
the different solutions, the problems with each of those, and possible
suggestions for ways around the problems. If we could have something
like that ready for the Montr=E9al meeting I think that meeting could be
a lot more productive.

Marc, do you think you could be editor of something like that? I know
you don't feel ready to do all the TMQL/TMAPI/etc parts of it, but you
don't need to write absolutely all of it so much as define the
structure of the paper, write most of it, and collect and edit
contributions from various people.=20

(I would prefer to do this myself, but I need to do something similar
on the TNC, and there should be another SAM draft, and there should be
a new XTM syntax draft, as well as a draft of the first GeoLang PSI
set, all of it before Montr=E9al, so...)

I think if we had something like this ready 2-3 weeks before Montr=E9al
the meeting would be in a much better position to settle this issue in
a proper way, and for people and national bodies who won't be there to
make their opinions on the issue known.

[1] <URL: http://tmapi.sourceforge.net/ >

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