Re: [xtm-wg] Questions on topic maps

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Ivan A. Uemlianin
| 
| 1. topic.scope
| 
| I notice that in ISO 13250 topic elements can have scope attributes,
| but that in XTM (I'm using the 10th Feb 2001 spec) the scope element
| cannot occur in topic elements.  Why the change?

Scope only applies to the characteristics of topics, not to the topics
themselves. Names, associations, and occurrences may all have limited
validity, but not the topic itself.

In ISO 13250 the scope on <topic> was just a shorthand and the topics
specified in that attribute were intended to be 'inherited' to the
scopes of all the characteristics of that topic.

I don't know precisely why this was changed, but I do think the change
makes a lot of sense. It is rare that one wants to apply scope in this
way, it can in any case be done by other means, and having scope on
topics tends to confuse people anyway.

| 2. role.class
| 
| In some work on the topic map data model (specifically Lars Marius
| Garshol's infoset-based proposal 20010618), association role items may
| be an instance of only one class.  

This is the same in both the ISO 13250 and XTM 1.0 syntaxes. I don't
know of any data model proposal where this is different.

| Although this seems reasonable prima facie, there may be cases where
| a single entity takes more than one role in an association.  

True. There is a well-known example in the Italian Opera topic map,
where there is a death-of-character association for the character
Floria Tosca, who commits suicide. The result is the following
association:

  <death-of-character>
  opera:       Tosca
  perpetrator: Floria Tosca
  character:   Floria Tosca
  method:      jumping from roof

| Isn't this best represented as a single role item with a list of
| classes (rather than a number of role items, each referring to the
| same topic)?

There is actually a many-to-many relation here, in the sense that a
topic may play multiple roles, while the same role may be played by
multiple topics. I think choosing to group under role players or role
types are both reasonable approaches, though grouping under role type
seems to me the best solution.

Whichever approach one chooses there will be two choices: either there
must be a restriction that groups cannot be repeated (only one
association role with each type in an association / only one
association role with each player in an association) or the structure
of association roles in an association may be unconstrained.

Specifying and maintaining such a restriction is extra work, and not
having it means extra bother for API/model users (and it also does not
feel like The Right Thing).

For this reason I chose the simpler route, where an association role
essentially represents a topic's involvement in an associations. This
is, I feel, semantically clear, and at the same time simpler in actual
use. Having the collection of association roles a topic participates
in (as seen from the topic) contain association roles that only the
topic itself participates in also seems cleaner to me.
 
| We are tracking topic map and TMQL development and obviously
| understanding the theory helps implementation enormously.

I assume the 'we' here refers to Jura Technology? I would be very
curious to hear what you are doing with topic maps, and I am sure most
others on the list would as well.

--Lars M.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Secure your servers with 128-bit SSL encryption! Grab your copy of
VeriSign's FREE Guide "Securing Your Web Site for Business." Get it now!
http://www.verisign.com/cgi-bin/go.cgi?a=n094442340008000
http://us.click.yahoo.com/6lIgYB/IWxCAA/yigFAA/2U_rlB/TM
---------------------------------------------------------------------~->

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/