[sc34wg3] Re: [topicmapmail] Multiple scopes on associations
Lars Marius Garshol
sc34wg3@isotopicmaps.org
22 Oct 2001 10:41:32 +0200
* Martin Bryan
|
| I thought the plan was to develop a topic map model that would be
| suitable for both 13250 and XTM. It would seem we are not, according
| to the messages I have been reading. This leaves me thoroughly
| confused.
It is my intention to develop a model for 13250 and XTM, and it is
also the intention of many others. Some people, however, have a
different agenda, as you've noticed.
The requirements document for the foundational model work will make
this clear to all (at long last).
| If we are only doing one for XTM, are we doing one for the result of
| merging two or more maps, or one for a single map?
We must do all of these things, for XTM and for 13250.
| If we allow for the merging of two maps containing matching
| associations, where themes are used to distinguish between the maps
| being merged, don't we automatically end up with sets of scopes on
| the resultant map? If so why have a different model for handling the
| merged map from that for handling single maps?
There is no difference in this case between a single topic map and
multiple topic maps. You may just as well have duplicated topic
characteristics with different scopes in a single map as when merging
multiple maps.
As for why merging must necessarily give us sets of scopes I don't
think that's the case at all. All the software that actually does
implement merging does so using single scopes.
| If we are trying to do a model that can also be used for 13250 then
| we have to allow for sets of scopes in any case (the model for scope
| is topic+).
Not at all. topic+ translates to a set of topics. That's a single scope.
What SRN is talking about is a distinct set of sets of topics. This
would translate to
<!ELEMENT scope (set+)>
<!ELEMENT set (topicRef+)>
| If the model is not to be used for 13250 then why are we discussing
| it on the SC34 WG3 mailing list? Lets remove this subject from that
| list if we agree it is XTM specific. Lets start discussing a model
| for 13250, please.
13250 incorporates both the HyTime-based syntax and the XTM 1.0 syntax.
The model must cover both.
--Lars M.