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

[Lars Marius Garshol]

* Marc de Graauw
| 
| Hmmm. There are statements that are very hard to scope. 'Marc de
| Graauw' is my name in any context. [...] Most scopes I can think of
| (region, language, time period, profession etc.) are much more
| restrictive than I want. So what scope do I choose?

I wouldn't choose any scope at all. I don't see that any scope that
you might add to the name would provide any useful information to
anyone. As you say, that *is* your name, irrespective of context.

Using scope to create topic name namespaces is a different use of
scope from the constraining of validity, and the two should not be
confused with one another.

| I cannot publish PSI's as I am not an organization with the
| long-term commitment that publishing PSI's requires, but maybe you
| could :-)

You could, Marc. A PSI just needs a publisher. A publisher that will
be around in perpetuity is better than one that won't, but such
publishers are in short supply, and people will use what they find
useful in any case. (That is, don't require things to be so perfect
before you do them that you prevent yourself from doing anything at
all.)
 
| The association I want to scope is a mapping between elements in
| Business vocabularies, i.e. 'company_name can be used as
| CustomerName'.  CustomerName and company_name are (names of) topics
| themselves. I do not use subject indicators because these assertions
| are unidirectional, i.e. I do not know whether 'CustomerName can be
| used as company_name'. When I scope the assignment with {Sales}, I
| want to assert that the mapping maybe used for the business
| processes of the department Sales. When I scope with {Sales,
| Marketing} I want to assert that the mapping maybe used for the
| business processes of the department Sales and for those of
| Marketing. When I do not scope explicitly, I want to assert that the
| mapping is valid for all Business Departments, not only as a
| coincidence (all existing business departments to have this this
| mapping) but as a general rule (the definition of CustomerName is
| such that it is a subset of company_name and thus the mapping is
| always valid).

This sounds to me like a good and pragmatic use of scope. The validity
may not actually be unconstrained, but within your topic map it is
unconstrained. 

| Now when I merge, I will often need to clean up the resulting topic
| map. For instance, the resulting Topic Map might have two
| associations:
 
| - 'CustomerName can be used as company_name' within scope {Sales}
| - 'CustomerName can be used as company_name' within scope {Sales, Marketing}
| 
| The first association can be thrown away, since the second one
| already says that the mapping is valid for business processes of the
| Sales department, and if the Topic Maps are large this would result
| in an enormous clutter of redundant associations. So my application
| needs a process that cleans up the resulting Topic Map according to
| this rule: If there are two associations that are equal in all
| respects except scope, and the scope of the former one is a subset
| of the scope of the latter one, the former one can be removed.

Yes, but this assumes that scope is a union.

| Now when the unconstrained scope is the set of all topics, I could
| use the unconstrained scope for associations that are valid for all
| business departments, and this rule would work fine. For instance,
| when a Topic Map would contain:
| 
| - 'CustomerName can be used as company_name' within scope {Sales}
| - 'CustomerName can be used as company_name'
| 
| the first association would be cleaned up because {Sales} is a
| subset of the set of all topics, and this is what I want.

As I showed, if scope is an intersection it would work equally well if
the unconstrained scope is the empty set.
 
| When your interpretation of the unconstrained scope were implemented
| in the Topic Map engine I use for merging, I could no longer use the
| unconstrained scope for this purpose, because the Topic Map engine
| would generate:
| 
| - 'CustomerName can be used as company_name' within scope {Sales}
| - 'CustomerName can be used as company_name' within scope 
| {reified_originating_topic_map}
| 
| and {Sales} is not a subset of {reified_originating_topic_map}. This
| is what I mean when I say your solution does not scale well when we
| expand scope.

Agreed. (Unless the reified_originating_topic_map is added to *all*
the scopes.)

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