[sc34wg3] SAM-issue term-scope-def

[Bernard Vatant]

*Lars Marius Garshol

> Ok. So what I hear is that some people would prefer to get rid of
> scope altogether. To me that means that we have to reconsider what we
> are doing. Either we are rearchitecting topic maps completely from top
> to bottom, or we are merely strengthening the existing standard.

I don't know if you count me among those "some people", but if yes, I think there is a
misunderstanding.
Scope, is a very useful and important feature, simply we should make it more powerful by
giving means to specify its semantics, in a backward compatible way. That's not discarding
it. The comparison Kal made with <instanceOf> is good. Scope as is it now could be
understood as a convenient shortcut for something that could be expressed in more specific
ways.

That does not mean complete standard rearchitecting, simply adding semantics to one
feature.

> Now, the requirements document that we already published[1] says that
> we will preserve backwards compatibility as far as we can. Discarding
> the TNC may conceivably fit within that scope (provided we push hard,)
> but I don't see how discarding scope altogether could do that.

Agreed. Discarding scope completely is something I did not think about. I simply said that
if we provide ways to provide more semantics to scope, consistent with a general way to
deal with reification, it might be that scope use dies out by itself in the long run. But
only users will tell.

> * Lars Marius Garshol
> |
> | So I do think scope can be useful, and although I agree that the
> | scope does not contain any information about what each theme is
> | doing in the scope applications know this. They can figure this out
> | either by recognizing the themes, or by recognizing what they are
> | instances of.
>
> * Bernard Vatant
> |
> | But if this information was carried in a standard way by a role
> | specification in scoping association, the applications would be able
> | to process it in a standard way, not through an ad hoc case-by-case
> | process.
>
> Possibly. I am not sure role types would give you so much more than
> the types of themes, but that's a discussion I am not very eager to
> start.

Well. I think I should start another thread on that difference between scope type and
scope role.
If we go towards refining the notion of scope, it's very important IMO.

> What we were discussing was whether scope is the intersection of its
> themes, the union, or simply unspecified.

As I tried to explain in my first post on that, the issue is certainly undecidable in the
present state of scope, because any decision has to rely on the semantics of the scoping
association. So, default of semantics, the answer is "unspecified".
I've suggested a way to decide it when roles in the scoping association are specified
(union for the same role, intersection otherwise)

The roadmap it seems could be:

1. Precise that scope, as it were, is a simple but poor-semantics process of specifying
context of validity, but that it's up to applications to decide how they deal with it,
because the very lack of semantics does not allow to set general rules for merging.

2. Propose an extended and backward-compatible way to refine the scope semantics, e.g. by
expliciting the scoping association, and the roles of each scoping topic.

It could seem reasonable to finish with 1. and cast it in the standard, and proceed to
further reflection on 2.

Bernard

-------------------------------------------------------------------
Bernard Vatant
Consultant - Mondeca
www.mondeca.com
Chair - OASIS TM PubSubj Technical Committee
www.oasis-open.org/committees/tm-pubsubj/
-------------------------------------------------------------------