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] XTM-ISS Basic Public Topics (was Re: Suggested public topic: "singleton")


Geir,
I am glad you agree about the importance of "singleton".

Besides singleton the following themes
seams to be the most important (or basic) public topics:

instance-of
class-of
container = contains
containee = contained-by
super-class = genus
subclass = species

I think that basic public topics (BPT) should play
a major role in the interchange syntax model.

In other words XTM software should be required to
understand minimum set (common denominator) of basic public topics.
It may or may not understand other (industry-specific) public topics sets.
It may use other public topic sets as a referential metadata.

Somebody can argue that XTM software should not be required to
know anything about public topics in order to function correctly.
I would ask then what in their opinion "function correctly"  stands for?

I perceive set of BPT as "moral rules" or "social norms" for XTM software.
:-))
One does not need to know the moral rules and social norms in order to
exist,
but one need to know moral rules and social norms in order to coexist with
others.
Topic Maps is about mergeability hence they are about coexistence.

Two persons can not co-exist (merge) in the same place if they
do not share moral vocabulary.

Forget about general-purpose merging. It never happens.
Merging is always for some particular reason.

When two company merge they right away start merging their departments.
It is only possible if they know types of those departments.
For example, accounting should be derived from a "singleton" BPT.
It just does not make sense to have two accounting departments.

XTM software built for a specific industry may have additional system public
topics (SPT) vocabulary.
The intersection of all SPT vocabularies(common denominator) should form
BPT.

Anybody want to add to the BPT set?

Should we add:

instantiation
containment
agent
target
result
action
consequence
...
etc.

Or should we try to keep this set to the minimum?

Thanks,

Nikita.


Nikita Ogievetsky
http://www.cogx.com
nogievet@cogx.com
(917)406-8734
Consultant in XML/XSLT/Xlink/TopicMaps

Geir Ove Grønmo
> * Nikita Ogievetsky
> | There have been several proposals on how to link
> | association with a topic link.
> | 1)turn association into a topic
> | 2)bring "id"-s on associations into the standard
> | 3)add "topic" attribute on associations
> |
> | I have reservations against all three suggestions.
> | Firstly, suggestion 1) depletes (as far as I am concerned)
> | the main concept of TopicMaps, which is:
> | "anything whatsoever" can be a topic.
> | And topic's participation in associations is just another piece of
> | information about a topic.
> |
> | >From this point of view topic "marriage" participates in
> | association between "husband" and "wife" by playing role of the subject
of
> | this association.
> |
> | It can be expressed by means of "type" attribute on association or
> | adding an assocrl with type="this-assoc-subject" or
> | "topic-this-assoc-is-instance-of"
> |
> | Suppose you want to supply any additional information about
> | a particular marriage.
> | Then you create a topic corresponding to this marriage, let's say
> | "marriageAtoB".
> | This "marriageAtoB" is of course of type "marriage".
> | Now the marriage association between A and B has a narrower subject of
> | "marriageAtoB".
> | As simple as that.
> |
> | There is one peculiarity though:
> | Only a single association in a given scope can reference this topic.
> | This can be achieved by adding "singleton" to the super-types of
> | "marriageAtoB"
> | If there are two associations pointing to the same singleton type in the
> | same scope, they should be merged.
> | <topic id="marriageAtoB" types="marriage singleton">..</topic>
> | <assoc type="marriageAtoB">
> | ..
> | </assoc>
> | or
> | <topic id="marriageAtoB" types="marriage singleton">..</topic>
> | <assoc>
> | <assocrl type="this-assoc-subject" href="marriageAtoB">
> | ..
> | </assoc>
> |
> | ------
> |
> | Suggestions 2) 3) above yield to jeopardizing integrity which is clear
from
> | the following:
> | 2)
> | <topic id="t2" types="some-other-assoc-type">
> | <locator href="a" type="is"/>
> | </topic>
> | <topic id="t1" types="some-assoc-type ">.</topic>
> | <assoc id="a" type="t1">...</assoc>
> | 3)
> | <topic id="t2" types="some-other-assoc-type">.</topic>
> | <topic id="t1" types="some-assoc-type ">.</topic>
> | <assoc topic="t2" type="t1">...</assoc>
> |
> | Integrity is broken in both cases if
> | Topic "t2" is not an instance of "t1"
> |
> | So having simultaneously both {id and type} or {topic and type}
> | on association (or on any other non-topic xtm element)
> | is a very subtle matter and can not be used without
> | rigorous xtm schema constructs (to be defined yet).
>
> I can't agree with you more. I had a discussion about this issue the
> other day and the outcome was that the implications of non-topic topic
> map object having both an id, a type and a characterizing topic was
> totally _unclear_.
>
> The singleton idea I really like. It makes the confusion go away.
>
> Geir O.
>




-------------------------- eGroups Sponsor -------------------------~-~>
Last minute trips at  
first-rate discounts 
from Hotwire.
http://click.egroups.com/1/9727/4/_/337252/_/971275420/
---------------------------------------------------------------------_->

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

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



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


Powered by eList eXpress LLC