[sc34wg3] Re: [topicmapmail] Multiple scopes on associations

[Lars Marius Garshol]

* Lars Marius Garshol
|
| XTM 1.0 is very clear on this, even if ISO 13250 is not.

* Martin Bryan
| 
| You are sensitive. My statement is about your interpretation of
| Steve's model, not the XTM model. (see below)

I wasn't paying attention, sorry. I think my DTD fragment is an
accurate description of how SRN thinks scope should be represented
(although he uses multiple s-nodes on each association), but the
ultimate authority on that must of course be himself.
 
* Martin Bryan
|
| does the merging of a set of added themes to a set scopes result in
| a single scope or a set of sets?

* Lars Marius Garshol
|
| A single scope in XTM 1.0.
 
* Martin Bryan
|
| So the resultant scope statement is a set containing the scopes
| assigned by the merged maps and the set defined by the association.

If you by "the merged maps" mean "the added themes defined by the
<mergeMap> element referring to the containing topic map", then yes.

* Lars Marius Garshol
|
| In PMTM4 I think the added themes do not increase the number of
| scopes, but I could be wrong.
 
* Martin Bryan
|
| How does this square with your claim that:
| 
| | What SRN is talking about is a distinct set of sets of topics. This
| | would translate to
| |
| |   <!ELEMENT scope (set+)>
| |   <!ELEMENT set   (topicRef+)>

As I interpret SRN the intention is that if two associations equal in
all respects but scope are encountered they are merged into one
association with two scopes.

If, on the other hand, an association is read in from a topic map that
is referenced by a <mergeMap> with added themes, that association will
have a single scope, but one that has themes added to it.

Again, SRN is the authority on this, but this is my understanding.

To put it another way: in PMTM4 associations may have multiple
s-nodes, representing multiple scopes, in order to deal with this
first case.

| What an earth does the definition of Base name information items
| (which your fragment identifier points to) have to do with this
| question? 

I don't see any difference between base names, occurrences, and
associations with respect to this issue. Either they all have multiple
scopes, or none do, especially as in PMTM4 they are all associations
anyway.

| The definition of Association information items scope statements in
| the referenced document is "This is the set of topic information
| items that represent the scope of this association. The
| interpretation of this value is dependent on the application. The
| set may be empty. " I note that it is a set, which is what I agree
| it should be. Not a single item, as XTM seems to require.

XTM doesn't require a single item. 2.2.1.6 says 

  "Every characteristic has a scope, which may be specified either
  explicitly, as a set of topics, or implicitly, in which case it is
  known as the unconstrained scope."
 
| The relevant statement in the XTM <association> element definition
| of your model, "If the <association> element has a <scope> child
| element, that element is processed according to the rules of section
| 3.14, with the new association information item as the current
| information item. " This appears totally unhelpful as far as this
| question is concerned.

I think I've understood this now. You want to know what happens when a
<mergeMap> element with added themes refers to a topic map containing
an association with a non-empty scope.

These are the different alternatives, as far as I can tell:

 - ISO 13250: the added themes are added to the single scope of the
   association  

 - XTM 1.0: ditto, according to
   <URL: http://www.topicmaps.org/xtm/1.0/#elt-mergeMap >. Note that
   this says "the scope", clearly implying that characteristics have
   but one scope.

 - Infoset model: ditto, as described in
   <URL: http://www.y12.doe.gov/sgml/sc34/document/0242.htm#d1e1076 >.

 - PMTM4: the added themes are connected to the s-node the association
   already has, and no new s-node is created for them. (I think.) This
   is equivalent to the statements above, just expressed using a
   different formalism.

In short, the four 'specifications' all seem to agree on this.

--Lars M.