[sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep')

[Lars Marius Garshol]

It seems to me that this issue depends on the term-scope-def issue[1],
in that it depends on whether a scope is made up of the intersection
of its themes or whether it is defined by each of those themes
individually. (Note: previous drafts of the SAM said "union", but
meant "intersection".) I think that before we have agreed on this we
won't be able to make any progress.

Let's assume for the moment that a scope *is* made up from the
intersection of its themes. If we then have the three scopes

  1. {}
  2. {a}
  3. {a, b}

it follows that characteristics in 3. have a more restricted validity
than those in 2., and that those in 1. are the least restricted of
all. 

Given this, let's look at the proposed ways to represent the
unconstrained scope (the first four from Marc, the last from Bernard):

  1. It is the empty set.  

     To me this solution seems reasonable, although it is not free
     from problems.

  2. It is the set of all topics.

     This has the problem that this makes the unconstrained scope the
     most restrictive of all scopes. It is only valid when *all*
     topics apply. Clearly, this makes no sense.

  3. Say nothing about the 'settiness' of the unconstrained scope.

     This does not work, unfortunately, since the SAM says that
     [scope] is a set of topic items and will require a specific
     representation for the unconstrained scope.

  4. The unconstrained scope is the set of all topics that are 'known'
     to be relevant for a Topic Map to an application.

     This is what ISO 13250 does, and as Marc has pointed out it just
     does not work.

  5. It is made up of the topic map itself.

     This corresponds well with common sense, but it would require the
     topic map topic to be added to all the scopes in the topic map in
     order not to wreak havoc with the restrictiveness ordering.

So I think we can dismiss 2., 3., and 4. straight away (in this
universe, that is). 1. and 5. require a closer look, I think.

--- 1. The empty set

* Marc de Graauw
|
| The reason it is undesirable for the unconstrained scope to be the
| empty set is that applications may very well decide to ask questions
| such as "is that scope a subset of this set of topics?". Since
| scopes are sets, such questions are natural. If the unconstrained
| scope is the empty set, no scope would be a the subset of the
| unconstrained scope when it would be more natural to expect every
| defined scope to be a subset of the unconstrained scope
| One can expect a lot of applications to use scope in such a way that
| a topic characteristic assignment in scope {a, b} is valid to a
| wider extent than an assignment in scope {b}. Since assignments in
| the unconstrained scope are always valid, it would seem more natural
| to define the unconstrained scope as {a, b, ... all other topics
| ... } then as {}.

This position assumes that scope is not a intersection, but that each
topic contributes individually. If scope is an intersection it makes
sense for the unconstrained scope to be the empty set. You would then
ask: which of the scopes {} and {a} (or {a} and {a, b}) have wider
applicability, and clearly that would be the first.

* Bernard Vatant
|
| Saying that the unconstrained scope is an empty set is a non-sense
| [...]

Maybe it is, but you have yet to argue that point, Bernard.


Later on, we will want a "find all characteristics valid in scope
X"-operator, and looking into this in my opinion favours this
solution. The desired result of that operation (still assuming scope
is a union) is shown in the table below. (I use {} to mean the
unconstrained scope.)

  X        | characteristic scope  | result
  ---------+-----------------------+-------
  {}       | {}                    | valid
  {}       | {a}                   | invalid
  {a}      | {}                    | valid
  {a}      | {a}                   | valid
  {a}      | {a, b}                | invalid
  {a}      | {b}                   | invalid
  {a, b}   | {}                    | valid
  {a, b}   | {a}                   | valid
  {a, b}   | {a, b}                | valid
  {a, b}   | {a, b, c}             | invalid
  {a, b}   | {d}                   | invalid

So it would seem that a characteristic is valid in context X as long
as its scope is a subset of X, and as far as I can make out this
resolution causes no problems with that.


--- 5. The topic map topic

As Bernard says, this solution is intuitively appealing, but in the
universe where scope is an intersection it only works if *all* scopes
have the topic map topic added to them. Once they do then the only
difference with resolution 1. is whether or not the topic map topic is
present in all scopes.

Marc was uneasy about what this would mean for processing, but I see
no problem there. A topic map processor would, if necessary, create a
topic item reifying the topic map item, and move on. This is no
different from how HyTM importers are required to create topics
representing the sort-theme and the display-theme.

The question is: what would be the gain in requiring every scope to be
expanded with one theme? It's not clear to me that that makes a lot of
sense or in any real sense simplifies anything. Conceptually, it is
correct, but I am not sure it makes sense to require it to be
represented explicitly.

Furthermore, what happens with merging then? I import topic map A,
then import topic map B, and finally I merge them, producing topic map
C. Now, what is the scope of the unconstrained characteristics coming
from topic map A? Topic map A, or topic map C?


However, as I said, I think this issue very much depends on the "is
scope intersection or union" issue (term-scope-def). We should create
another thread for that issue first, settle that, then come back here
and settle this issue.

I'll start that thread right away.


[1] <URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=term-scope-def >

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