[sc34wg3] Scope, again

[Marc de Graauw]

* Martin Bryan

| The situation with the Dutch term is straightforward, but the
| English/French/... name gives us an entirely different set of problems.
| Instead of:
|
| >                      topic-scope
| >                          (T)
| >              topic        |        scope
| >               (R)         |         (R)
| >                |          |          |
| >                |          |          |
| >    (A)--------(C)--------(A)--------(C)--------(x)
| >  Paris has name      Paris has name          Dutch
| >     "Parijs"       "Parijs" in Dutch
| >  (A is the assertion
| >      above)
|
| we either have a whole set of assertions for single languages, or we need to
| create a set in place of the final (x). At what level in the models would
| responsibility for a) defining the set,

Since scope is a set, I should have written {Dutch} on the right-hand side. Of
course {Dutch} then has to be decomposed to a set-member assertion. So I think
the set would be defined in the SAM if one authors a Topic Map with a
SAM-based engine, or in XTM or HyTM if one hand-crafts a Topic Map.

| or b) identifying that a name is
| used by more than one language, reside?

I don't really get the point. This responsibility would surely rest with the
Topic Map author, being the person with domain knowledge, wouldn't it?

| [NB: The Paris case is a good example of what happens is practice. If a
| specific language does not have its own version of a place name then the one
| applied by the natives is adopted. So the fact that there is no language
| entry for Tamil in the topic map name list for the Paris topic does not mean
| that Tamil does not recognize Paris, only that it uses the default name. It
| is for this reason that I am very much against treating languages as scopes,
| which restrict the rules you can apply to the selection of names.]

Many folks use scope for languages, and so do I. But I am willing to learn. In
a previous posting
(http://www.isotopicmaps.org/pipermail/sc34wg3/2002-July/000447.html) you
argued:

| When 13250 was being defined things like language and dates were
| seen as being likely to be defined as facets rather than scopes as
| they are typically externally defined.

So what would be the preferred way to handle language in XTM?

On a sidenote, ISO 13250:1999 says: "NOTE 40: The topic referenced via the
type attribute can have many names in scopes designed for many different user
contexts, including many different natural languages ..." See also Notes 42,
46 and 51.

XTM says (http://www.topicmaps.org/xtm/1.0/#elt-baseName): "Natural language
discrimination between base names may be specified by a child <scope>
element."

This seems to suggest scope is the way to handle natural language.

| > (1) Knowledge implies belief.
| > (2) 5 + 7 = 12
|
| For reasons why I doutbt (2) see
| http://www.sgml.u-net.com/maths-conundrum.doc :-)

Ah, yes. Your link is broken, it should be:
http://www.sgml.u-net.com/maths-conundrum.htm
I was merely trying to say someone can assert a proposition to be
unconditionally true. Whether someone is right in asserting this is another
question.

| Yes. But how can you say that "Language of the name Parijs is Dutch" in any
| way changes the validity of the assertion that "Paris has the name Parijs"?

You are right, Paris always has the name "Parijs". I guess I should have said:
'"Parijs" _is_ the name of Paris'. This assertion is valid in Dutch but not in
most (all?) other languages.

| > So scope to me is just a way to make a specific kind of assertion: an
| > assertion which limits the validity of another assertion.
|
| This is not how I would phrase it. I would suggest that "scope identifies
| those domains in which the assertion is known to be valid: if no scope is
| stated then the assertion is valid in any domain". Note the subtle
| difference due to the fact that something can be known to be valid in one
| domain, and yet be valid in another domain without the topic map author
| being aware of that fact.

You are right.

| > If different
| > people use scope in different ways because the SAM lets them, that is not
| > going to help interoperability.
|
| But restricting the ways in which scope can be applied will not help the
| acceptance of topic maps. We need to be very careful not to forbid any
| situation in which the use of scope is relevant.

Agreed.

Marc