[sc34wg3] SAM-issue term-scope-def

[Lars Marius Garshol]

* Graham Moore
| 
| i.e. that scope is no more than a lazy way of stating things about
| associations and that really to be useful associations should be
| further qualified by other associations.

That would land us where RDF is now, and they have been having lots of
debates on how to qualify statements. As far as I am aware they
haven't really solved that problem to anyone's satisfaction yet.

Scope is simpler, and that's also its strength, I would say. For one
way to strengthen scope, see Steve and Geir Ove's paper on scope[1].
 
| I would like us to try and get some consensus on this idea and put
| something into the spec to reflect this. I dont think we need to
| ditch scope just make it very clear that its a sloopy way to work. 

If we agree that it is I think that would be an appropriate way to
handle the issue, but I don't actually think this is true. (I'll
explain why below.)

| I also think this goes hand in hand with ditching the topic naming
| constraint as a MUST do and introducing typed names instead of
| scoped names.

These issues are certainly related.
 
| 'gra' scoped by {shortname} is a typing action

Absolutely. This is just a workaround for the problem that names
cannot have types. Most name scopes (in practice) are name types.
 
| 'granada' scoped by {city} is a topic qualifying action
| 
| [...] The second example is just awful - what is really being said
| here is that the TOPIC not the name has some relationship with
| 'city'.

Agreed. This a terrible abuse of scope, but unfortunately typical of
the examples people have throwing around.
 
| I would like to see that when someone queries a map with a topic
| name they can get back multple topics.
| 
| i.e query => get topics by name 'Washington'
| 
| Washington (located England)
| Washington (located US)
| 
| and I would be horrified if all the names of these topics were
| scoped by some topic that should really be associated properly with
| the topic.

Amen.

However, scope *can* be used appropriately, and when it is it can be
very very useful. I've been saying this for a while, so I'll actually
step forward and provide some examples for once. 


  [gbk : charenc = "GBK"
                 = "Windows CP 936" / microsoft]

This says: most people call this character encoding GBK, but Microsoft
calls it "Windows CP 936". A variation on this is to scope names with
languages, which is very very useful, as it provides any easy way to
make topic map-driven applications support multiple languages.

A similar usage is when two classification systems have been merged,
and some concepts appear in both, but with different names, and
perhaps at different points in the hierarchy. Using scope you can
qualify names and associations by what system they came from, and
users can choose to see the merged result, only the structure of one,
or the structure of both but using the names of one.


  [karnataka : province = "Karnataka"
                        = "Mysore" / old-name]

Here we are saying that this province is today known as Karnataka, but
it used to be called Mysore. Obviously, the scope could be restricted
to a specific time range, but I didn't see any point in that.


  instance-of(devanagari : instance, abugida : type) / daniels
  instance-of(devanagari : instance, alphasyllabary : type) / bright

This is saying that according to Bright Devanagari is an
alphasyllabary, whereas according to Daniels it is an abugida. This
would allow me to let my scripts and languages web site be agnostic as
to what authority on scripts it should follow.


  written-in(vietnamese : language, chinese-s : script) / formerly

This is saying that Vietnamese used to be written with Chinese
characters, but that it no longer is.


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.

For example, we've been thinking of making the Omnigator look at the
HTTP Accept-language header (set from user preferences in most
browsers) and set the user context filter accordingly. This would mean
that most people would see the Genji topic map in English, while the
Japanese would see it in Japanese. This would be done through scope
filtering and published subjects, and the only missing piece is really
20 lines of code...

[1] <URL: http://www.ontopia.net/topicmaps/materials/scope.htm >

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