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: [xtm-wg] re topic.scope


> the problem you seem to be alluding to only exists
> in the time-space between the creation of a topic and the assignment
> of its first characteristic(s) in the scope(s) within which you want
> that topic to have interpretation. 

The problem is about representing intensional properties of concepts
(ie topics); in other words, of constraining characteristics of topics,
specifically, the scopes within which characteristics may appear and
the scopes outside of which a topic is necessarily inaccessible.  The
ISO 13250 syntax implies such a constraint (as I argue below), but xtm
is weaker.

> I wonder if the problem here is practical or conceptual?

The problem is conceptual.

(a) semantic implications of syntax
    (i) (in)dependent nature of topics
    (ii) Semantic implications of syntactic shorthand
(b) concepts and contexts


(a) semantic implications of syntax
    (i) (in)dependent nature of topics

> In topic maps, a topic is simply the sum of its characteristics. It
> has no independent existence. 

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>

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 )+ >


    (ii) Semantic implications of syntactic shorthand

> 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. 

[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>


(b) concepts and contexts

The above two points provide a basis for my interpretation of topic
maps, ie that topics have an existence independent of their names and
occurrences, and that topics can be scoped.  This interpretation is
based directly on the syntax of the standard, and the semantic
implications of that syntax.

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').

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

Practical considerations are derivative of these conceptual issues.

Regards

Ivan

Ivan Uemlianin, PhD
Head of Topic Map Development
Jura Technology Ltd

6 Tai Seion
Llanddeiniolen
Caernarfon
Gwynedd LL55 3AF


Head Office:
35 Norroy Road
London SW15 1PQ


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