OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xtm-wg] re topic.scope


Ivan,

I don't have time to answer all your points in detail, so forgive
me for commenting quickly on your first and then skipping straight
to the heart of the matter.

At 05:07 23.07.2001 +0100, ivan@linux.celtic.co.uk wrote:
>In ISO 13250 the production rule for the topic element is [1], which
>entails the validity of [2].  In other words, a topic has an existence
>independent of its characteristics (ie a topic does not depend on
>characteristics for its existence).
>
> [1] <!element topic ( topname | occurs )* >
>
> [2] <topic></topic>

This is (almost) true.

[2a] <topic id="foo"></topic>

would be more accurate.

>Defining a topic to have no existence independent of its characteristics
>would require a production rule like [3], where a topic can only exist
>if it has characteristics: 
>
> [3] <!element topic ( topname | occurs )+ >

Also true, and we did in fact seriously consider making this the
content model for the topic element.

[2a] -- assuming it did not play a role in any associations (which
possibility is the reason for insisting on the presence of the ID
attribute) -- would be a dimensionless point that would be essentially
meaningless and useless until such time as it was given some topic
characteristic or other.

Remember, topic maps are about information management. A topic with
no characteristics can serve no useful purpose in *that* context.

>> ISO 13250 is very clear (see clause 5.2.1, and especially note 22) that
>> the use of a [scope] attribute on a <topic> element is a *syntactic
>> shorthand*.
>
>However, this particular syntactic shorthand has semantic implications
>(which may not have been intended, I concede).  Note 22 says that a
>topic's scope attribute specifies, "once for all", "the themes that
>are common to the scopes within which all the names and occurrences of
>a topic are valid".  In other words, specifying a scope attribute 's' of a
>topic is equivalent to specifying a rule that all present or future
>characteristics of that topic must include 's' in their scopes. 

No, I would dispute this, although the standard may not be clear
enough on the matter. You have to distinguish between the topic map
document, as expressed in the interchange syntax, on the one hand,
and the processed topic map on the other. You also have to distinguish
between <topic> elements, and "topic" nodes or objects in the fully
resolved internal representation.

Many topic elements may all reify the same "real world" subject. To
the extent that the topic map processing system knows this to be the
case (due to the use of "identity" attributes in 13250, through the
topic naming constraint, or by some other means), the result of
processing those topic elements should be a single topic node or
object in the internal representation.

The importance of this is that the syntactical short-cut offered by
the "scope" attribute on the <topic> element (or indeed the "scope"
attribute on the <topname> element, or the "addthems" attribute on
the <topicmap> element) really is only syntactic and applies only to
the subelements of the element on which it occurs.

Themes specified on a <topic> element are only "inherited" by names
and occurrences that are subelements of that element.

>[4] & [5] below (your [1] & [2]) are not identical because of this
>implicit rule about any future additions to the topic. 
>
> [4] <topic scope="biology"><name>dysfunction</name></topic>
>
> [5] <topic><name scope="biology">dysfunction</name></topic>
>
>If [4] & [5] are identical, then adding an identical object to both
>should result in two identical objects.  This does not happen,
>however. For example, adding the node <name>anomaly</name> to both
>results in [6] & [7], which are certainly different: 'anomaly' in [6]
>has scope="biology"; 'anomaly' in [7] has universal scope.
>
> [6] <topic scope="biology"><name>dysfunction</name>
>                            <name>anomaly</name>
>     </topic>
>
> [7] <topic><name scope="biology">dysfunction</name>
>            <name>anomaly</name>
>     </topic>

You are thinking too much in terms of syntax. The syntax is only
a way of serialising the model; the model can be serialised in many
different ways, some more compact, others less so. There is, believe
me, no "implicit rule about any future additions to the topic".
If you add a new (name or occurrence) characteristic in the same
scope as all the existing (name and occurrence) characteristics,
then you can continue to use that particular shorthand. But there
is nothing to stop you adding a name in scope Y to a topic that
currently only has characteristics in scope X, irrespective of how
that topic might be serialised.

>My interpretation is also influenced by academic work in
>AI, linguistics, philosophy and psychology arguing that interpretation
>of concepts (or 'subjects' to use the standard's terminology) always
>occurs in some context (if 'topic' represents 'subject', I take
>'scope' to represent 'context').

There is obviously a close correlation between between scope and
context, although I don't see it as being quite the same as that
between topic and subject. (Our paper "Towards a General Theory of
Scope" says more on this matter, see
http://www.ontopia.net/topicmaps/materials/scope.htm.)

>As I said earlier, ISO 13250 allows these interpretations and I'm
>happy to work with that standard rather than the weaker xtm.

XTM is not weaker (at least in this respect); it merely does not
allow so many syntactic variations. *Nothing* was removed from
13250 when creating XTM unless it was felt to be syntactic sugar or
seriously misguided and open to misuse (as in the case of the
so-called mnemonics). The fact that "scope" attributes are a mere
shorthand was the very reason for getting rid of them!

Thank you for pointing out that 13250 is insufficiently clear on
this issue. As convenor of SC34/WG3 I shall make sure to bring it
to the attention of the editors!

Regards,

Steve

--
Steve Pepper, Chief Executive Officer <pepper@ontopia.net>
Convenor, ISO/IEC JTC1/SC34/WG3  Editor, XTM (XML Topic Maps)
Ontopia AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway.
http://www.ontopia.net/ phone: +47-23233080 GSM: +47-90827246


To Post a message, send it to:   xtm-wg@yahooGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@yahooGroups.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC