De-overloading scope WAS(Re: [sc34wg3] Question on TNC / Montreal minutes)

[Lars Marius Garshol]

* Marc de Graauw
| 
| I did not express this correctly. When one applies the TNC, that
| means on must merge topics, so I should have distinguished merging
| topics and merging Topic Maps. That gives: 
|
| <corrected version of Marc's original posting>
|
| When we look at the situation with the TNC and merging, there are
| actually three relevant possibilities:
|
| 1) Apply the TNC within a Topic Map and with merging
| 2) Apply the TNC within a Topic Map but not when merging Topic Maps
| 3) Never apply the TNC
|
| </corrected version of Marc's original posting>
| 
| This means a TM author wants to ensure topics have unique names, and
| use scope when they do not, possibly to give users a cue what the
| name refers to. But the author realizes that using the TNC when
| merging with an arbitrary Topic Map is not safe. So when Topic Maps
| are merged, one must either not apply the TNC in the resulting Topic
| Map or have a human fix nameclashes in the resulting Topic Map. It's
| a bit like using the TNC as an authoring tool to track homonyms
| within a Topic Map.

I think this is an interesting idea, and it goes in the direction I
would like to see this debate move. What you have said here is
essentially that the author should be allowed to choose to what extent
the TNC should apply.

Where I would like to see us end up is with two kinds of merging:

 (1) Merging by URI

 (2) Merging by topic characteristics

Merging of type (1) should be part of the model, enforced, and always
happen, within topic maps and across topic maps. Merging of type (2)
should rely on additional information, be controllable by the user,
and support different approaches for different needs.

As you imply I think we will see situations where people do want the
TNC, or the TNC within topic types, or merge by occurrence values, or
by associations, etc etc etc
 
* Marc de Graauw
|
| 'Paris' {France} versus 'Paris' {Texas}

* Lars Marius Garshol
|
| Actually, I think this particular example is just misinformed. I
| wouldn't use scope in this way.
 
* Marc de Graauw
|
| Graham once said this is terrible abuse of scope and one should use
| associations, and you probably mean just that. True, but only if one
| is interested in the city-country association in a Topic Map. If one
| is not, but does want to disambiguate both Parises, scope can be
| used as a 'lazy' way to do that.

Certainly. That's not an argument for the TNC, though.

| One problem with replacing this with associations is that TM engines
| (i.e. the Omnigator) don't know which association to show to a user
| to disambiguate the name. So when use scope 'Paris' {France} and
| 'Paris' {Texas} the Omnigator will show "Paris (France)" and "Paris
| (Texas)" to the user, which is helpful. If we model Paris/France and
| Paris/Texas with associations, a user browsing a "Paris" must look
| at all (possibly many) associations to know which Paris is meant
| here. When you type "Paris" in britannica.com, the first thing
| Britannica asks is:
|
|       Did you mean...
|       Paris (Fr.)
| 
| That's scope, and I don't see what's so wrong with it.

What's wrong with it is that you've essentially taken what Steve calls
the disambiguating association and duplicated it in the scope of the
name in a way that is abuse of scope. Paris is the name of Paris, not
just in France, but also on the moon. In other words, the validity of
the name Paris is not limited to France, even though the scope claims
that it is. (There's also the redundancy problem, but I guess you've
already spotted that.)

Now, a better solution to this problem is simply to have some sort of
published subject that allows you distinguish disambiguating
association types from other association types. You could make
located-in a subclass of "disambiguating association" and once we
update the Omnigator it *will* know how to display this, without
requiring you to abuse scope or duplicate information.

And, of course, you could use scope this way even if we remove the
mandatory merging of topics whose names are equal in the same scope...

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