[sc34wg3] Scope - SAM (as in TM model) - Inferencing

[Marc de Graauw]

* Patrick (reminder by Sam)

| We came very close to resolving the questions regarding scope in the SAM
| (standard application model) while in Montreal but there is one
| outstanding issue.
|
| The general (but not universal) consensus was what no inferences can be
| made based upon the presence or absence of a scope set for an
| association, or the presence or absence of one or more topics in the
| scope set. All that means is that inferencing rules are not being stated
| in the SAM. Applications are free to make inferences, warranted or
| otherwise, on any basis they choose.
|
| Can someone articulate a reason why the SAM should provide a rule for an
| application level behavior, such as inferencing?

Objection, Your Honour! This line of questioning is leading.

If I have read the Montreal minutes correctly this issue is about
prop-structured-scope
(http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xt
m&id=prop-scope-structure) and term-scope-def
(http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xt
m&id=term-scope-def).

There are one explicit and two rather implicit assumptions in this argument.
It runs:

(1) [explicit] The SAM should not define application level behaviours
(2) [implicit] Inferencing is an application level behaviour
(3) [implicit] Structuring scope means inferencing
Therefore:
(4) [explicit] Structuring scope should not be in the SAM

The argument invites readers who deny (4) to assert:

(5) The SAM should define application level behaviours

I will not do that, I agree with (1). It is different however with the other
assumptions.

(2) [implicit] Inferencing is an application level behaviour

I this means implementing predicate logic or propositional logic in the Topic
Map standards, agreed. We should not pursue that a this moment, it is much too
complicated and would probably swallow all available time. Actually, one of
the major attractions of Topic Maps for me was - still is - that Topic Maps
are much more down-to-earth than a lot of other AI initiatives. Having said
that, I think the standard already defines a lot of inferencing in the broad
sense. When a Topic Map processor concludes (based on the rules defined in the
SAM) that two topics have the same identity, and therefore those topics should
be merged, than that is inferencing. So there is a place in the SAM for some
forms of inferencing and not all forms of inferencing are application level
behaviours.

(3) [implicit] Structuring scope means inferencing

I do not agree at all. Structuring scope is just about making explicit what
scope actually means, and thus is a knowledge _representation_ issue and not
inferencing in itself.

Let's take an example from my Oxford Concise English Dictionary (Oxford 1999,
ISBN 0-19-860259-6):

Topic - n. 1 a subject of a text, speech, conversation etc.
2 (Linguistics) that part of a sentence about which something is said,
typically
the first major constituent
- ORIGIN C15: from L. topica, from  Gk ta topika, lit. 'matters concerning
commonplaces' (the title of a treatise by Aristotle).

My case (I've read the entire Montreal minutes (good work, Patrick!) but the
natural conciseness of such notes makes me uncertain whether I've completely
understood everything, so apologies if I repeat discussions) is that probably
a lot of people will want to express simple facts such as:

[ t1 = 'topic' / linguistics english ]

'Topic' is the name of a subject in scope linguistics and English. That means,
both linguistics and English should 'apply'. 'Topic' is not the name of this
subject when 'Dutch' and 'linguistics' apply. People will also want to express
facts such as:

[ t2 = 'Rome' / dutch english ]

Rome is the name of a city when Dutch or English applies. Either one is
enough.

Now if we leave it up to applications to define what [ t = 'N' / X Y ] means,
results of merging are going to be unpredicatable. If application A asserts
[ t = 'N' / X Y ] meaning 'N' is the name of this topic when X AND Y apply,
and application B asserts [ u = 'N' / X Y ] meaning 'N' is the name of this
topic when X OR Y apply, those topics should not merge, but they will. I would
not want to limit people to express anything, just make explicit what they
express.

If we take the 'all subjects' view
(http://www.y12.doe.gov/sgml/sc34/document/0327.htm#N221) it is easy to
express both facts:

[ t = 'N' / X Y ]   (Topic t has name N when X AND Y apply)
[ t = 'N' / X ; 'N' / Y ]   (Topic t has name N when X OR Y applies)

It is still pretty much up to applications what AND and OR mean, since in this
context the semantics is still rather vague. But it is clear what the effects
of merging will be, and the undesired merge described above will not occur. If
applications do not need to express AND/OR at all, they can simply say [ t =
'N' / X Y ], have their own interpretation and all will be fine and dandy.

Do not forget that most users will not make Topic Maps in XTM. Topic Map
engine vendors will supply pretty user interfaces and the users will click
their mouses to make statements such as: 'The name of x is Rome when the
language of choice is Dutch or English'. If one Topic Map engine serializes
this as [ t = 'N' / X Y ] and another as [ t = 'N' / X ; 'N' / Y ] because the
standards do not define an interpretation, those Topic Maps are not even going
to be interchangeable among Topic Map engines without loss of semantics!

Since:
NOT (3) AND
NOT ALWAYS (2)
I will maintain:
(4) [explicit] Structuring scope should be in the SAM

At least as far as the interpretation of the appearance of an element in the
scope set is concerned.

Regards, Marc

Note: Basically I think this is all just Lars' redundancy elimination argument
phrased differently - possibly needlessly elaborate. Right, Lars?