[sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep')
Marc de Graauw
sc34wg3@isotopicmaps.org
Fri, 7 Jun 2002 21:45:14 +0200
[Bernard Vatant]
> Marc
>
> Your analysis is very interesting, although I don't share your conclusions. I
> don't think
> I ever expressed on that point, so here goes.
>
Bernard,
Thanks for your reply. I am happy to see that one of the experts in the field
agrees with me on some accounts and even happier to see he disagrees on others
;-)
> Saying that the unconstrained scope is an empty set is a non-sense, saying
> it's the set of
> all topics in the topic map is as silly as can be, as you very well show ...
> and saying
> it's universal is arrogant :))
Possibly. I do fear that saying it's universal is will cause all kinds of
problems, it's just that I don't see them yet!
> What is the natural (implicit) scope in a topic map? Well, it's obvious
enough
> : it is the
> topic map itself !
> All unscoped characteristics I consider valid in the limits of the topic map
I
> built, but
> I can't infer of their validity outside its borders.
>
> So what? If I want to explicit this implicit scope, it contains *exactly one*
> topic, which
> represents the topic map itself.
> It's not empty, and it's not universal.
I briefly thought about this solution, but quickly - maybe too quickly -
dismissed it. I think there are 3 problems with it:
1) It is kind of strange to put this in a standard like the SAM. It would
either require Topic Map authors to reify their Topic Map, or have a Topic Map
merge process do it for them. While it is certainly often useful to reify your
Topic Map, _requiring_ it would seem unnecessary.
2) What if you really want to say something that is valid always and
everywhere? What if I want to express "The subject with identity 'MdG' has as
its name 'Marc de Graauw', always and everywhere!" Your solution would
automatically scope it down to the containing Topic Map.
3) It scales in strange way when we expand scope. Let me explain.
When I have a topic map with:
- a single genuine topic, name='Marc de Graauw'
- a topic reifying the Topic Map, say 'The Scoping Problem Topic Map'
- five themes, say 'nl', 'en', 'fr', 'de', 'es'
First I have as the scope of the name 'Marc de Graauw' the set {nl}. Next I
find that this name is valid in English as well, so I scope the name with {nl,
en}.
Et cetera, the scope becomes {nl, en, fr} and {nl, en, fr, de}. Then I find
the name is valid in Spanish as well, and since it is valid in all languages
under scrutiny, I decide to say the name assignment is valid in the
unconstrained scope. Then I have as scope all of a sudden: scope = {The Scoping
Problem Topic Map}. Alle the previous steps seem to bear a natural relation to
each other, the last step does not. When (if) we want to build applications
that are able to say: the scope {nl, en, fr} is a subset of the scope {nl, en,
fr, de} and do something useful with that information? It would require special
processing rules to do this with the reified Topic Map as scope because of this
scaling problem.
It is certainly a useful approach, but I think it is more an approach for a
Topic Map author, not one we could use in a standard. We could, however, say
nothing in a standard about what the unconstrained scope is (solution 3 in my
list), and let Topic Map authors use the solution you describe whenever they
wish.
>
> In mathematical terms, if TM is the topic map : unconstrainedScope(TM) =
> {reified(TM)}
>
> This reified topic map, explicited at merging time, will be the only topic to
> be
> considered by <mergeMap>
>
> It seems to me both intuitive, clearly defined, scalable, and does not seem
to
> raise any
> philosophical nor implementation or merging problems.
All true. There is another advantage: while the Topic Naming Constraint is
under fire, it is very often useful (the more I think about it the better I
like it). I think the problem is not so much the TNC but using the TNC *in the
unconstrained scope*. Your approach would remove that problem.
> Moreover, demanding that
> merging
> explicits this implicit scope through a reification of the original topic map
> (s) keeps the
> more simple track one can imagine of the merging: original topic maps are
> represented as
> topics in the result of the merging.
>
> And this is a very generic principle. Merging is like gathering information
> from a third
> party ...
>
> If A asserts (x killed y) with no restriction, this means it is valid in the
> unconstrained
> scope of A.
> Any third party using this assertion should say : (according to A) (x killed
> y)
>
> Bernard - ready for the flame war :o)
Shoot!
>
> -------------------------------------------------------------------
> Bernard Vatant
> Consultant - Mondeca
> www.mondeca.com
> Chair - OASIS TM PubSubj Technical Committee
> www.oasis-open.org/committees/tm-pubsubj/
> -------------------------------------------------------------------
>
>
> ----- Message d'origine -----
> De : "Marc de Graauw" <marc@marcdegraauw.com>
> A : <sc34wg3@isotopicmaps.org>
> Envoye : vendredi 7 juin 2002 16:55
> Objet : [sc34wg3] Which set is the unconstrained scope? (SAM-issue
> 'scope-unconstrained-rep')
>
>
> > I have raised an issue in private conversation with Lars on the
> > unconstrained
> > scope, now listed as "scope-unconstrained-rep". Description: "How should
> > the
> > unconstrained scope be represented? Essentially, it is the scope made up of
> > all
> > subjects, that is, the universal set.". I would like to expand on this.
> > (Since
> > this is an old issue, it was probably raised by others too.)
> >
> > The current text of the SAM mentions: "If the scope of a topic
> > characteristic
> > assignment is the empty set the statement is considered to have unlimited
> > validity, and it is said to be in the unconstrained scope." I remarked that
> > this should be the universal set rather than the empty set. (Or rather,
> > since
> > scopes consist of topics, it should be the set of all topics.) Lars agreed
> > that
> > this was an issue but was concerned about the repercussions for
> > applications.
> > When an iteration over the elements of a scope is defined, this would imply
> > an
> > interation over the universal set, which is not desirable.
> >
> > The current positions on what the unconstrained scope is are:
> > - ISO 13250: all the topics in the entire topic map ("This International
> > Standard does not require that scopes be specified explicitly. If the scope
> > of
> > a topic characteristic assignment is not explicitly specified via one or
> > more
> > scope attributes, the scope within which the topic characteristic applies
> > to
> > the topic includes all the topics in the entire topic map; this special
> > scope
> > is called the unconstrained scope.")
> > - XTM: does not say anything about which set the unconstrained scope
> > represents. ("Every characteristic has a scope, which may be specified
> > either
> > explicitly, as a set of topics, or implicitly, in which case it is known as
> > the
> > unconstrained scope. Assignments made in the unconstrained scope are always
> > valid.")
> > - PMTM4: The scope comprised of the null set of topics -- the "no-topic"
> > scope
> > - DRM: nothing, scope is for the SAM
> > - SAM: the empty set, see above
> >
> > The ISO 13250 defintion is strange, since the unconstrained scope here is
> > defined to be equivalent to the scope made up of all topics in the Topic
> > Map.
> > I.e. when we have a topic map which consists of two topics:
> >
> > <topicmap>
> > <topic id="NL">
> > <topname>
> > <basename>Netherlands</basename>
> > </topname>
> > </topic>
> > <topic id="MdG">
> > <topname>
> > <basename>Marc de Graauw</basename>
> > </topname>
> > </topic>
> > </topicmap>
> >
> > then ISO 13250 would imply that this is equivalent to:
> >
> > <topicmap>
> > <topic id="MdG">
> > <topname scope="MdG NL">
> > <basename>Marc de Graauw</basename>
> > </topname>
> > </topic>
> > <topic id="NL">
> > <topname>
> > <basename>Netherlands</basename>
> > </topname>
> > </topic>
> > </topicmap>
> >
> > Since both Topic Maps will behave differently when merging with a third
one,
> > I
> > do not see how this could be correct. It is also strange to use a topic to
> > scope it's own name as a general principle, although this would be correct
> > in
> > some circumstances. Further, the second Topic Map would seem to suggest
> > that
> > the basename "Marc de Graauw" is not valid outside the defined scope (or
> > not
> > known to be valid), while the first Topic Map would seem to suggest that
> > there
> > is no known limitation to the validity of the basename "Marc de Graauw".
> > Though
> > strictly speaking this interpretation is up to applications, it still seems
> > counterintuitive.
> >
> > 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 {}.
> >
> > There is, I think, a natural solution to the representation of the
> > unconstrained scope. We must distinguish between explicitly defined scopes
> > and
> > implicitly defined scopes (XTM already does, and ISO 13250 speaks of
> > explicitly
> > and not-explicitly specified scopes). Then an explicitly defined scope is a
> > scope element (in XTM) or attribute (in HyTM) or any corresponding data
> > structure in an application with topics as elements (elements meant here in
> > the
> > mathematical sense, as elements of a set). An implicitly defined scope is
> > one
> > required by the processing of a Topic Map syntax, i.e. the unconstrained
> > scope
> > when no scope is explicitly defined. Then we could say that iteration is
> > allowed over explicitly defined scopes, and not over implicitly defined
> > scopes.
> >
> > If that route is chosen, then there are several possibilities on the
> > unconst
> > rained scope:
> > 1. It is the empty set, which is undesirable IMHO. In short, it forces
> > applications to implement behaviour which is at odds with what the standard
> > says.
> > 2. It is the set of all topics. Any topic is an element of the
> > unconstrained
> > scope, and any set of topics is a subset of the unconstrained scope (though
> > not
> > necessarily a proper subset). The elements of explicitly defined scopes are
> > accessible by applications, the elements of implicitly defined scopes (the
> > uncontrained scope) are not.
> > 3. Say nothing about the 'settiness' of the unconstrained scope. Explicitly
> > defined scopes are sets of topics, what implicitly defined scopes (and thus
> > the
> > unconstrained scope) are is up to applications. The only thing that matters
> > about the unconstrained scope is the consequences it has on merging.
> > 4. The unconstrained scope is the set of all topics that are 'known' to be
> > relevant for a Topic Map to an application. These would include:
> > - all topics in the Topic Map under scrutiny
> > - all topics in Topic Maps that are to be merged, either through <mergeMap>
> > elements (in XTM) or through user-driven or application-driven merging.
> > This is an adaptation of ISO13250 which removes the undesired effects
> > described
> > above, but retains the idea. An advantage is that the unconstrained scope
> > remains accessible, i.e. an iteration over the unconstrained scope is
> > possible.
> > It does not remove other peculiarities of the 13250 definition. The
> > unconstrained scope will change when a topic is added to a Topic Map, and
> > the
> > unconstrained scope will be a different thing for different Topic Maps.
> >
> > I think 2 would be the best route unless there are difficulties involved
> > which
> > I have overlooked.
> >
> > Marc
> >
> >
> >
> > _______________________________________________
> > sc34wg3 mailing list
> > sc34wg3@isotopicmaps.org
> > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
> >
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>