ISO/IEC JTC 1/SC34 N0331

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

Title:	Report of August 2002 Meeting of ISO/IEC JTC1/SC34/WG3 in Montréal
Source:	SC34/WG3
Project:	All SC34/WG3 Projects
Project editor:	All SC34/WG3 Editors
Status:	Report of WG3 meeting in Montréal
Action:
Date:	2002-08-29
Summary:	Report of WG3 meeting in Montréal
Distribution:	SC34 and Liaisons
Refer to:
Supercedes:
Reply to:	Dr. James David Mason (ISO/IEC JTC1/SC34 Chairman) Y-12 National Security Complex Information Technology Services Bldg. 9113 M.S. 8208 Oak Ridge, TN 37831-8208 U.S.A. Telephone: +1 865 574-6973 Facsimile: +1 865 574-1896 E-mailk: mailto:[email protected] http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm Ms. Sara Hafele, ISO/IEC JTC 1/SC 34 Secretariat American National Standards Institute 25 West 43rd Street New York, NY 10036 Tel: +1 212 642-4937 Fax: +1 212 840-2298 E-mail: [email protected]

Montréal meeting of WG3

The meeting was held at the Wyndham International hotel in Montréal on 2002-08-03 to 2002-08-05. The meeting room was kindly made available by IDEAlliance.

About this report

The following notes reflect an unedited (or approved) version of the WG3 meeting. Realizing after the fact that ad hoc recording of decisions in the course of ongoing discussion may not be capturing precisely the full import of the decisions of the WG, Lars Marius Garhsol and Patrick Durusau have been discussing ways to more accurately capture the WG decisions. Currently those discussions are focusing on the preparation of "decision statements" which will be short statements using the appropriate terminology that will be presented to the group for its approval at the time of decision making. It is anticipated that the use of a projector to allow participants to view the statements will aid in this process.

In the meantime, these notes have been asssembled from the rough meeting notes (see below) and may contain decision statements that are more meaningful if assembled into proper terminology and located within the larger discussion of the group.

Meeting content

The authors of the Standard Application Model presented their work, and the contents of their list of issues were then discussed. The outcome can be found below.

Resolved issues

assoc-role-player-type

Must both [role playing topic] and [role type] have values (on association role items or may they be null)?

The following considerations were raised by the meeting:

XTM does not require either to be non-null, the reasoning being that the author might not know the role type or the role player, but still know there is such a role.
Conceptually, the type and the player are present, but unknown.
A PSI for "unknown" does not work, since its use will imply that all unknown role types and role players are the same subject, which is not the case.

The meeting concluded that both [role playing topic] and [role type] must have a non-null value. When deserializing XTM documents the processor must supply topics with no property values to fill the properties if the role player or role type are undefined in the XTM document.

merge-same-subj-ind-addr

Is it allowed for a topic to have the same locator item both as subject identifier and as subject address? If it does, must not this mean that the topic has two subjects?

The following considerations were raised by the meeting:

If a topic has the same URI as both subject identifier and subject address, that seems to imply that the topic has two subjects, where one is the subject indicator and the other is the thing described in that indicator.
However, a subject indicator may describe itself, in which case the topic will be correct.

The meeting concluded that this case was pathological, but not necessarily incorrect. No constraint for this case will be added to the model.

op-topic-map-compare

Should we define an equality criterion for topic map items? There is no need for duplicate removal for topic maps, but on the other hand that would be what is needed to define the conformance requirements on serialization implementations.

The meeting concluded that defining an equality comparison was generally useful, and that it was needed for the definition of conformance in the syntax specifications.

term-empty-set

Do we need to define what the empty set is?

The meeting concluded that this was not necessary. The empty set is the set with no members, and everyone knows that it is. The meeting also concluded that the empty string was equally well known to be the string with no characters. Neither of these terms therefore need to be defined.

prop-schema

Should topic map items have a [schema] property that may contain their schema definition(s)? This would make it clear where to find the topic map schema. On the other hand, the TMCL specification should perhaps have its own rules for specifying how to find the schema of a topic map. It may be better to keep the levels strictly apart.

The following considerations were raised by the meeting:

It is not the task of ISO 13250 to specify constraints on topic maps. This is to be left for TMCL (and others).
Definitions of types and constraints on instances of the types are closely related.
Types are topics, therefore information can be layered onto them using the existing model. Support in the model itself is therefore strictly speaking not needed.

The meeting concluded that a [prop-schema] property on the topic map item was not needed, nor any similar properties on the topic map items that might be constrained by a schema. It also concluded that the umbrella PSIs should be taken out of the Reference Model.

prop-value-null

If it (the [value] property on base name items) may not be null, why may it be empty?

The following considerations were raised by the meeting:

The empty string is a valid string. Someone may decide to name a topic with an empty string.
If the empty string is forbidden because it's not a useful name, what about single-character names? And if they are forbidden, what about two-character names? How do we know a-priori what is useful and what is not?

The meeting concluded that having the empty string as a value is OK, while null is still not allowed.

term-subject-identity

Is the term "subject identity" needed? It is defined in XTM 1.0, but it is not clear that there is any use for it. The XTM 1.0 definition is: That which makes two subjects identical, or distinguishes one subject from another.

The following considerations were raised by the meeting:

There seems to be no difference between 'subject' and 'subject identity', which implies that one is superfluous.
There is a subjectIdentity element type in XTM, but this does not necessarily mean that 'subject identity' as a formal term is needed.

The meeting concluded that the term 'subject identity' is not needed, and can be dropped.

term-theme

Is the term 'theme' useful, or best forgotten?

The following considerations were raised by the meeting:

The term was introduced after someone found that a draft of ISO 13250 used the term 'topic' in 18 different senses, in order to keep the number of different uses of the same term down.
The expression 'scoping topic' or 'topic used in scope' carries the same meaning.
The term causes difficulties in translation, since not all languages have three different synonyms that can be cleanly mapped to 'topic', 'subject', and 'theme'.

The meeting concluded that the term was best dropped, and the phrase 'scoping topic' or 'topic used in scope' used to refer to the concept.

term-tm-processor

Do the definitions of the terms 'topic map processor' and 'topic map applications' have unwanted consequences for what software architectures can be conforming implementations of this standard?

The meeting concluded that as long as the conformance section is phrased correctly these definitions need not carry unwanted implications for architecture. The author will fine tune the prose to make sure this problem is avoided.

term-topic-characteristic-assignment

Are topic characteristic assignments statements about the topics's subject, or about the topic?

The following considerations were raised by the meeting:

To say that they are statements about the topic is to say that topics and subjects are the same thing.
If they are different, the 'topic' default PSI in XTM 1.0 is broken.
Related to the issue of whether it should be possible for one topic to reify another (that is, have another topic as its subject).

The meeting concluded that topic characteristic assignments were statements about the subject, not the topic. No decision was reached on the reification of topics.

term-topic-name

XTM 1.0 has a term "topic name", but it is not clear how it relates to the term "base name". Its use in XTM 1.0 seems to be inconsistent. Is the term useful, or should it be abandoned?

The following considerations were raised by the meeting:

The base name is the string inside the baseNameString elements, and the variant names are variants of that string.
This implies that a different name is needed for the whole ensemble of base name plus its variants, and this is what the term 'topic name' should be used for.

The meeting concluded that the term 'topic name' should be kept, and used for the base name and its variants. The base name item in the SAM should be called the 'topic name item', since it carries the base name and its variants.

variant-in-basename

ISO 13250:2000 does not restrict display/sort names to a single base name, by design. Is it acceptable for SAM to do so?

The meeting concluded that the base name/variant name model was an improvement on the HyTM model, and that in the case of HyTM topname elements containing multiple basename elements multiple topic names should be created, each repeating the display and sort names of the topname.

xtm-implicit-constraints

The XTM DTD contains a number of implicit constraints, such as that an addressable subject may not be used as a theme or a type. Should these constraints be mirrored in the SAM?

The following considerations were raised by the meeting:

Although the XTM 1.0 DTD seems to constrain where topics reprsenting resources may appear it does not actually do so, since even if a topic is referred to with a topicRef element it may represent a resource.
Constraints on the model instances carry a cost in terms of implementation effort, general complexity, and learning. The model should not have more constraints than necessary.

The meeting concluded that the SAM should not necessarily attempt to mirror the constraints implied by the XTM 1.0 DTD.

merge-prop-srclocs

Should source locators of B be copied into A? If they are, it is implied that A is the same topic map as B, which is not true. Also, topics reifying B will then also reify A, which means that any statements made about B will also apply to A.

The following considerations were raised by the meeting:

Clearly, implying that A and B are equal is wrong. Once merged in, the original topic map disappears (from the point of view of the master topic map).

The meeting concluded that the behaviour currently specified by the SAM was correct. The current behaviour is to throw away the source locators of subordinate topic maps merged into a master topic map.

topic-naming-constraint

Should the standard retain the topic naming constraint?

The following considerations were raised by the meeting:

The issue is essentially whether base names are just labels, or whether they are also unique identifiers within namespaces. In XTM 1.0 they are both.
To be able to label topics without being forced to use the labels as unique identifiers within namespaces is a reasonable requirement.
Being forced to make all labels unique identifiers makes topic map creation harder, and not everyone needs the benefit of being able to unambiguously address topics by their names. Addressing may in many cases just as well be done using URIs.
Making the topic naming constraint optional preserves backwards compatibility, while at the same time taking away the disadvantages of the topic naming constraint for those who do not wish to use it.
Base names intended to be used as unique identifiers within a namespace are written in a different way from base names which are not intended to be used in this way. That is, this is a property of each individual base name.
Authors need to be able to indicate within their topic maps how they want the topic naming constraint to apply.

XTM syntax modifications

The following alternatives (not necessarily mutually exclusive) were considered:

Allow authors to indicate for the entire topic map whether or not the topic naming constraint is to apply to that topic map.
Allow authors to indicate on mergeMap one of three options:
1. Follow author's instructions in merge-in topic map.
2. Apply topic naming constraint to all topics in merged-in topic map.
3. Do not apply topic naming constraint to any topics in merged-in topic map.
Considerations:
- Changing topic naming constraint settings in merged-in topic maps is likely to break those topic maps.
- Changing the settings also changes the semantics of the merged-in base names, which is a dubious thing to do.
- This option adds substantial complexity to XTM processing.
- Only having options a. and c. would make this less harmful.
Allow authors to indicate for each base name whether or not the topic naming constraint should apply to it. Possible ways:
1. Define a new element type label to be used instead of baseNameString to indicate when a base name is just a label.
2. Define a PSI that might be used in base name scope to indicate whether or not the name is a unique identifier.
3. Add an attribute to baseName to control this.
4. Allow label to be used instead of baseNameString.
5. Add an attribute to baseNameString.
6. Use a subelement of baseName to do the switching instead of an attribute.
Considerations:
- Gives authors maximum power.
- Using an attribute was considered poor modelling because that attribute would then really change the element type.
- Attributes are easy to use and understand and have minimal impact on the existing syntax.
- With attributes defaulting declarations in the internal subset can be used to set topic map-wide defaults without a special syntax for this being required.
- Using a subelement has all the disadvantages of new element types together with all the disadvantages of attributes.
Ditto for variant names.
- This would break backwards compatibility.
Add a new element type label that is structurally similar to base name, but to which the topic naming constraint does not apply.
- Introducing new element types means that topic maps in the new syntax will not work at all in XTM 1.0 implementations.
- Complicates the syntax by pushing the label/identifier split very high up in the document tree.
Add types to base names and use the type to indicate whether or not the topic naming constraint applies.
- Does not work, because some names of a given type may be identifiers, while others may not.

After much discussion it was decided to only choose number 3. A merge attribute is added to the baseNameString element, and given the values on and off, with on being the default (for backwards compatibility).

SAM model modifications

The following alternatives were considered:

Add a merge on/off property to the base name item.
- It was generally agreed that this is equivalent to using a property to indicate the type of the item, which is not the right way in the model, though less bad in the syntax.
Have two subtypes of base name: label and identifier.
- While esthetically appealing this complicates the model and its explanation, and also requires subtyping machinery to be added to the metamodel.
Represent distinction with scope.
- This is abuse of scope and was rejected for that reason
Represent distinction by reifying the base name item and using an association on the reifying topic.
- This is too heavy processing-wise, and also complicates the prose descriptions of the processing in the SAM too much.
- Using reification to change the semantics of a base name item is also not good modelling practice.
Have two different string properties on the base name item: one for labels and one for identifiers.
- Not quite as clean as 2., but less complication and still good enough.

The meeting concluded that 5. was the correct solution.

Feedback from national bodies on the resolution of this issue (both in XTM and SAM) is very much encouraged.

Unresolved issues

prop-scope-structure

Should it become possible for the scopes of topic characteristic assignments to have internal structure?

The following considerations were raised by the meeting:

Scope as it is currently defined is too weak.
The presence of a topic in a scope cannot be used to infer anything without knowledge of application conventions.
Reification of the topic characteristic assignment allows the assignment to be qualified using associations, which already have all the structure one might want.
Conventions for the use of scope are necessary, especially for merging.

No specific conclusion was reached. National bodies are urged to read the discussion paper on this issue and provide comments on the issue.

term-scope-def

This definition of scope is different from that of XTM 1.0 and ISO 13250:2000, in that it explicitly says topic characteristic assignments are valid for each of the subjects in its scope individually. Is that acceptable?

The following considerations were raised by the meeting:

It is possible to specify the structural rules for scope matching separately from how the scope is interpreted by applications.
The structural rules must be specified, but it is not clear that the interpretation rules need to be.
The resolution of this issue has consequences for the scope matching operators in TMQL, as well as inferencing based on topic maps in general, but may be left for higher levels.

No specific conclusion was reached. National bodies are urged to read the discussion paper on this issue and provide comments on the issue.

New issues

No new issues were raised at the meeting.

Instructions

The authors of N0329 and N0328 were instructed to continue their work on the Standard Application Model and the new XTM Syntax Specification, and prepare new drafts for the next meeting of SC34.

Next meeting

The next meeting of WG3 will be held in Baltimore, as a plenary SC34 meeting, in conjunction with the XML 2002 conference.

Full meeting transcript

The meeting transcript below was written by Patrick Durusau.

In attendance at meeting opening:

Jim Mason

Holger Rath

Graham Moore

Sam Hunting

Eric Freese

Steve Newcomb

Michel Biezunski

Patrick Durusau

Lars Marius

Nikita

Discussion of agenda and technical preparation.

ISO/IEC JTC1/SC34 N 325

SteveN: no reference model available (discuss if RM comes up in SAM)

Michel: should be time on the RM for discussion

Sam: what does the RM do? Introduction?

Sam: SAM should come first and then RM

Lars: could be Sunday or Monday for discussion of the RM

SteveN: locator references and what they mean is a profound issue,
will open up all sorts of things

Michel: will provide list of RM issues in the morning

Michel: new address

Michel Biezunski: new address

402 85th Street
Brooklyn, NY 11209
718-921-0901

Jim: trouble accessing OakRidge server? Sam, trouble with dialup. Jim
can't do anything about the server. But can't mirror the files due to
legal exposure, US claims right to re-distribute.

JTC1/newsite (ISO site)

Issue list from SteveP

1. Locator reference:

XTM: separates topics that represent a information resource and topics
that represent other things, what do locators reference, and what are
the consequences of that? and must they be resolvable? What if used as
a subject resource?

Graham: should continue the distinction (ditto, Lars, SteveN) and the
question is how to do it.

Lars: thing-described-on-date, proposal

SteveN: what if an address is used as a subject indicator? huge
difference between a name and a binding point.

Lars: does that kill topic name restraint?

2. Scope in XTM

ISO says scope applies when any theme applies, in SAM, when all themes
apply. How to represent unconstrained scope? all or any topics, look
at ISO/IEC JTC 1/SC34 N0327 for summary of these issues. (read for
this discussion)

3. Topic Naming Restraint:

SAM issue 'topic-naming-constraint'
Editor's draft 14 07 2002

4. XTM syntax spec

ISO/IEC JTC 1/SC34 N0328

5. SAM issues

- suitable minor issues
- assoc-role-player-type (1)
- merge-same-subj-ind-addr (1)
- op-topic-map-compare (1)
- term-empty-set (1)
- term-empty-string (1)
- prop-schema (1)
- prop-value (1)
- prop-value-null (1)
- term-subject-identity (1)
- term-theme (1)
- term-tm-processor (1)
- term-topic-characteristic-assignment (1)
- term-topic-name (1)
- xtm-implicit-constraints (1)
- merge-prop-srclocs (3)

- suitable larger issues
- prop-reifier-topic (1) (done on Saturday)
- names-as-subjects (1)
- locator-reference (1)
- term-subject-def (1)
- op-sorting (2)
- merge-use-of-schemas (2)

Issue (assoc-role-player-type):

3.9 Association role items

Must both [role playing topic] and [role type] have values?

Association role information items are equal if the values of their
[role type] and [role player] properties are equal.

Michel: relates to RM, minimal requirement for an assertion, what is a
well-formed assertion (RM) or what is a well-formed association (SAM)

SteveN: casting node, does it have to have a role type and a role
player? casting node has a subject, plays a role in an assertion, but
cannot also be an a-node, can be assertion-type node, only x-node

Graham, just be a this and a role

Lars, but the "this" may be unknown

Sam, advocates a no-exception graph

SteveN: if assertion has a role, that is unplayed, is there a casting
node present to represent that is it not played. No, no role player,
is there is nothing being played.

Lars, not required to have a player or a role type (in XTM) might not
have a role type because role in association is unknown; on the other
hand might know have a CEO but don't know who it is.

Graham, was a mistake in XTM to say don't have to have either.

SteveN, is syntax allows it to be done, processing model has to account for it.

SteveN: unknown subject, PSI? becomes a nexus and makes bad
connections, can't characterize an unknown because it is
unknown. nullness cannot be a subject,

Michel, but need to know what is empty in TM production

SteveN, can say things that are not done yet,

Lars, if have unknown topic as role type and player, saying they are
the same thing.

Lars, if want to represent unknown things, do it yourself.

Sam, if role type left out, is the author saying it is unknown or
simply not there?

SteveN, issues for processing XTM and SAM may be different, so could
have default role types, for XTM processing model

Graham: both should be required, meaningless without both: must have
role type and role player.

Nikita: what if want to say no players,

***Decision: Must have both role type and role player in SAM. In XTM
processing, will specify what default behavior occurs in absence of
either.

SteveN: (stated in RM terms) Casting node: has three things,
association, role type and role player

Graham: what should XTM processing model do when omitted?

Nikita, difference in nothing and none. if husband role player left out

Lars, always create same topic or new topic

Nikita, nulls are never equal, wants to introduce notion of null into
topic maps

Lars, every topic has the same subject, marriage association, role
wife, another association, role wife, must be the same
marriage. creates a problem if you use nullness

Nikita, RDF has nulls that don't merge

Michel: need to define null, nothing,

Lars, create topic with no characteristics or properties, if they
change it, they have changed the topicmap, a unique topic each time it
is created. Can't point at it because nothing is there

SteveN: recreating anonymous nodes

Mary arrives***

SteveN: anonymous node is better, it is not our purview to tell people
how to make TMs, only way what it means once it is created.

Sam: incorrectly making a set out of anonymous nodes

SteveN: fly in ointment, no necessary that every node has a demander,
can't ever be talked about.

Lars, now talking about scope of the standard

***Decision: In XTM syntax, in the absence of a role type and/or role
player, anonymous nodes are processor supplied. These supplied nodes
have no properties at all.

Lunch --

Issue (merge-same-subj-ind-addr):

Is it allowed for a topic to have the same locator item both as
subject identifier and as subject address? If it does, must not this
mean that the topic has two subjects?

Lars, have a URI and topic, say this URI points to subject indicator
and a subject

SteveN, possible for subject indicator to be itself (paper points to itself)

Nikita, offers the paper pointing to itself example.

***Decision: this is not an issue, it is OK (seriously weird)

SteveN: related issue, HyTM points to subject which may point to
itself. Asked another way, should it be possible to use a subject
indicator where the subject is an addressable subject? Should we say
something about it? Deprecate the practice?

If subject is addressable, should use resource ref.

Graham, must subject indicators be resolvable? Not enforceable and
probably should just say as matter of best practices.

SteveN: problem with web, idea of resource, confused with byte stream
and confused with a name, esp. TBL's mind. To get scaling, want to
have things pointed at by topic maps or topics, and those things have
to have identity.

Graham: want to have common agreement on identity.

Michel: identity and documentation, identity (topic connects to
related things) vs. documentation (subject indicators)

SteveN: pointing at the same thing but using different addressing schemes.

Michel: using XPointer and an ID to point to a resource, system has to
be able to say it is the same object?

SteveN: no, philosophically, has be a sense of identity that causes
two subject to be the same

Graham: subject indicators implied to be resolvable (information
resource implies this)

SteveN: wants a concept that address expression and it points at
something, but that something need not exists so long as it has
identity, but have to say that it has identity. (subject indicator)

Proposed: No -- subject indicators do not have to be
resolvable. Nikita says they don't have to be addressable but must be
resolvable (not necessarily by a computer)

SteveN: public confusion will result from this statement.

SteveN: has to be a perspective from the thing being addressed that it
is being addressed from two different directions

Graham: needs to be resolvable but not addressable, identity is just a
string of bytes

SteveN: don't confuse address of subject indicator with the subject indicator.

SteveN: what is difference in an opaque string that refers to
something vs. subject indicator that is also an opaque string?

Sam, Arch de Triumph in Paris, what is its identity? can make many
copies, but there is only one that is in the middle of paris in that
context. at a unique perspective and that is what gives it the
identity

Subject indicator has a context and a name does not, any copy will work

***Implied Decision: subject indicators do not have to be
resolvable. (but needs explanation to avoid confusion, always useful
to compare names in namespaces, intended to be unique in a namespace)

Nikita, should be an agreed upon perspective to determine what a
subject indicator means

SteveN: useful hueristic to to compare names in the same
namespace. Name is not the identity. Can agree on what to name
something.

Graham, is an information resource.

SteveN: does subject indicator mean you have indirection?

Graham, yes.

If there is a subject indicator then there is indirection, if there is
no indirection, it is OK. (can have agreement with yourself)

Issue (op-topic-map-compare):

Should we define an equality criterion for topic map items? There is
no need for duplicate removal for topic maps, but on the other hand
that would be what is needed to define the conformance requirements on
serialization implementations.

Lars, no way to compare entire topic maps b/c the purpose of
supression is to remove duplicates. Did not define suppression very
well, so has been re-defined for every type.

SteveN: is there a sense in which it has existent separate from the
document?

SteveN: what if I render the Opera topicmap as HTML files, a rendition
of it. Does the abstractio that represents the topic map appear in the
HTML file? Lars, says we lost it.

SteveN: talking about reifying the topicmap in the topicmap
itself. Graph always reifies itself.

Lars, topicmap item is there to be a root from which to find items.

Nikita, always uses topic to reify the topicmap, unconstrained scope.

Graham, has a topic that reifies the map, in SAM has first class link
that connects to topic items

SteveN, important to allow topic maps to talk about each other, x-nodes

Lars, do we need a rule to compare topic maps?

So we don't have to define export because with import two topic maps
should be the same.

SteveN: wants to traverse a topic map and see every item once

Lars: reify used in special sense, in the SAM. resource ref to the
topic map, reify topic map item

<topic>

subjectIndicatorRef (points to "tm")

SteveN: could find every topic from the topic of the topic map and not
from the topic map itself. means the topic map item is a house keeping
detail

***Decision: want comparison so conformance will work. without
defining export.

Issue (term-empty-set)
Do we need to define what the empty set is? And the empty string?

***Decision: No, applies to empty string too

Issue (prop-schema):

Should topic map items have a [schema] property that may contain their
schema definition(s)? This would make it clear where to find the topic
map schema. On the other hand, the TMCL specification should perhaps
have its own rules for specifying how to find the schema of a topic
map. It may be better to keep the levels strictly apart.

Graham, should be kept separate and TMCL should be responsible for
linking constraints to the topic map.

SteveN, what is the definition of a role versus constraints on the
topic map?

Nikita, agrees ISO 13250 should not define constraints on topic map

SteveN: important from casting role to find the topic node whose
subject is the association type. not talking about constraints, from
the perspective of an assertion, should be able to find the assertion
type. Assertion type may have one, or may have zero. Is that a good
idea?

Michel, should we consider this an application issue? or a default
assertion type

SteveN: need to establish a boundary on the territory.

SteveN: what is the difference in constraint and definition?

SteveN: role types are topics, assertion types are topics (really
there, may have to be supplied) What is relation between types and
roles, puts us in validation land, constraints. description is not the
same as contraint. RM if we want to say must have one of these must
have one of those, can assert in the topic map.

Do XML without DTDs, must be well-formed. Can't rule out information
from being in a topic map.

***Decision: Don't have to be able to reach topic map constraints from
the topic map itself but could be included.

***Decision: Take umbrella PSIs out of the reference model.

Base name items represent base names, and have the following properties:

1. [source locators]: A set of locator items. This is the set
containing the source locators of the base name.
2. [value]: A string. This string is the base name.

Issue (prop-value):

Is [label] a better name?

Martin Bryan: label would be a distinct improvement

Michel, base name and variant name are not the same thing. distinct,
can have as many base name as you want, with variants for each one

***Decision, depends on topic naming constraint, deferred

Issue (prop-value-null):

If it may not be null, why may it be empty?

Martin Bryan: if can't be null, why should we allow it to be empty?

SteveN: yes, empty string is a valid string (as opposed to null),

Michel, translation, word does not have equivalent

SteveN: someone may decide to name something with the empty string

SteveN: two topics with no name get merged with the topic naming constraint

***Decision: Cannot be null but can be empty string.

Issue (term-subject-identity):

Is the term "subject identity" needed? It is defined in XTM 1.0, but
it is not clear that there is any use for it. The XTM 1.0 definition
is: "That which makes two subjects identical, or distinguishes one
subject from another."

what is difference between subject and subject identity?

SteveN: confusing,

Michel, is an element name in XTM but don't need to change

***Decision: term "subject identity" is not needed. drop from glossary
for SAM

Issue (term-theme):

Is the term 'theme' useful, or best forgotten?

Michel: forget it

SteveN: only because after draft of 13250 had used topic with 18
different meanings, tried to make everything distinct, topic used in a
scope

***Decision: Forget it.

Issue (term-tm-processor):

Do the definitions of the terms 'topic map processor' and 'topic map
applications' have unwanted consequences for what software
architectures can be conforming implementations of this standard?

Lars, if not required by the conformance section, does this mean anything.

Michel: applications (not defined) use the topic map processor

***Decision: Lars is re-working the prose.

SteveN: don't care about serialization, not what a topic map processor does.

***Decision: agreed.

Issue (term-topic-characteristic-assignment):

Are topic characteristic assignments statements about the topics's
subject, or about the topic?

Lars, are subjects and topics the same thing or different?

Lars, reason why subject PSI in XTM is broken. occurrence is a
statement about the subject and not the topic.

SteveN: different classes of assertions, some roles in some
assertions, play a role in understanding the subject of the assertion.

***Decision: Agreed that topic-charactertic-assignments are about the
subject.

What about talking about a topic directly (as opposed to the subject)?
How to reify a topic with another topic?

Lars, should be able to talk about topics with another topic.

Michel, what is the difference in using the element of the target.

Michel, addressing nodes in the graph (RM) has a T node, how to make
another T node about it.

SteveN: must be in implementation land. unaddressable subject.

Graham: locator can be automatically assigned and used to address the
topic you want to talk about.

SteveN: reference model uses all assertions

Michel, can make assertions about assertions

Lars, topic items don't have a reifier properly (in SAM)

SteveN: when you point at, two ways to point, point at information or
point at something that is what you want to talk about.

Lars: have basename element, B node, and actually the name of
something, in subject land, when reify are talking about the name in
subject land.

Issue (term-topic-name):

XTM 1.0 has a term "topic name", but it is not clear how it relates to
the term "base name". Its use in XTM 1.0 seems to be inconsistent. Is
the term useful, or should it be abandoned?

Michel: just say base name.

***Decision: Just use base name.

(Does base name include all its variants?)

SteveN, should be subject maps and not topic maps

SteveN, base name is the string that is the heart of the base name,
and variants are variants of that string.

SteveN, variant baseNames?

***TopicName (includes a basename and all its variants) (topics have
multiple topicnames)

Lars, problem with HyTM and association of variant names with base names

SteveN, have a processing model for HyTM that fixes this problem

***Decision: A topic name element contains multiple base names, all
the display and sort names are repeated for all base names.

Michel, variants are just to help with processing of names for
particular applications

Mary, Japanese users mis-spell their names for an LDAP server

Mary, model should allow it

Michel, need an application layer to process mis-spelled words, don't
do it with topic maps

***Issue: Lars, wants to allow variants to be used to represent
natural language variants on a base name

Michel, would want to further restrict variant names, problem with merging

SteveN: baseName directly connected to the thing named, variant is
connected to the assertion between the baseName and the thing named

Issue (xtm-implicit-constraints):

The XTM DTD contains a number of implicit constraints, such as that an
addressable subject may not be used as a theme or a type. Should these
constraints be mirrored in the SAM?

SteveN: lets make SAM as clean as we can.

Lars, no other way around. XTM DTD looks as if certain things are
disallowed but they aren't.

***Decision: Not restricted the implied constraints in the DTD.

Issue (merge-prop-srclocs):

Should source locators of B be copied into A? If they are, it is
implied that A is the same topic map as B, which is not true. Also,
topics reifying B will then also reify A, which means that any
statements made about B will also apply to A.

Lars, topicmap tm1 and topicmap tm2,

SteveN: not how he sees topic maps working,

Graham, source locators are not part of the model, but if want to pull
other things later, may be valuable later on.

SteveN: if topic map #2 points to something in topic map #1,
srclocator must be there.

Graham, not correct to say this for topic maps themselves (after merger)

Nikita: once topic maps merge, they disappear,

Lars, yes but this is how they disappear

SteveN, make the two topicmaps managers that point to a master topic

***Decision: Don't merge srclocators when merging topic maps

- suitable larger issues
- prop-reifier-topic (1)
- names-as-subjects (1)
- locator-reference (1)
- term-subject-def (1)
- op-sorting (2)
- merge-use-of-schemas (2)

Present:

Lars Marius

Graham Moore

Holger Rath

Mary

Eliot Kimber

Steve Newcomb

Michel Biezunski

Eric Freese

Nikita

Patrick Durusau

Discussion of agenda for today's meeting.

Topic Naming Constraint

SteveN: objections raised are valid, but doesn't mean that it is
wrong, just a question of how broadly it should be applied. may be
able to label things without using namespaces

SteveN: options for topic naming constraint 1) vendors want to make
creation of topic maps easy, onerous to insist on making distinct
namespaces and applying unique names within namespaces, 2) other
people may not want to rely upon names to disambiguate topics or may
not care

Eliot: given topic identity, the value of topic naming constraint
becomes questionable

Michel: that assumes a well structured topic map, people create topic
maps in different environments, must use the topic naming constraint
for merging, could do on optional basis, should not be obligatory

Nikita: now happens automatically, should have option to merge or not
to merge, a method to execute topic naming merging within in a scope

Eliot: want it to be optional, should be able to say if you expected a
topic naming constraint

Michel: problem is that topic map are on the web and can be used on any manner

Nikita: also goes back to use of base name, is it unique name?

Graham: only work around is to have an occurrence of label and put the
information there

Eliot: requirement of TNC means you have to do unnecessary disambiguation -

Michel: define subject identity when it is the same

SteveN: does anyone want to get rid of TNC? No.

SteveN: does anyone think it should always be required? No.

SteveN: not talking about authoring - only what does merging mean.

Lars: always the case that abc is always associated with xyz -

***Consensus: We empower authors to decide whether the names in topic
maps are to be understood with the TNC rule or not.

TNC DTD Syntactic change options:

Add attributes to certain XTM DTD elements to allow authors to convey
when Topic Names should be considered to be defined in terms of the
TNC.

1. Add property to TopicMap element

property 'tncRule' values (true| false) implies that all names within
this topicmap and any merged maps are bound, or not, by the TNC.
(unless overidden, default is yes)

2. Add property 'tncRule' to MergeMap element that overides any value
set on topicmap 'tncRule' that dictates if the topics in the map to be
merged are constrianed by the tnc. This overides any 'tncRule'
properties in the topicmap referenced by the mergemap href property.

3. Add a 'tncRule' property to baseName element with allowed values
(true|false) to indicate if this name should be considered to be bound
by the tncRule of the topicmap. This overiddes any higher level
tncRule defined on this map but MAY OR MAY NOT overide any tncRule
defined in the mergeMap property.

4. Add 'tncRule' property to VariantName to allow authors to specify
if this VariantName should be bound by the TNC.

5. introduce new characteristic type "label" structurally identical to
basename but does not have TNC

6. basename can have types (defer to scope discussion)

TNC Rule with regard to merging topics.

SteveN: establishing requirements, do, leave alone, etc.

Eliot: Must have 1,2,3 , but not interested in 4

Michel: 4 makes applications more difficult

Nikita: 2 needs a selective rule, for selective merge (Eliot, can have
multiple merge maps for topics already)

Nikita: merge topics that are within a particular scope

SteveN: don't mix up scope (defines namespaces) with whether we are
using scopes as a namespace

Michel: scopes has different uses, one for merging.

SteveN: bear in mind that merging can be forced by other means,
critical thing is to be able to turn it off.

Lars: more important to Michel to get merges than to avoid, but Lars
thinks unwanted merge are to be avoided. Merges are risky

Nikita: After merger without TNC, have two topics with the same names,
after merger has topic with same name twice.

Sam: Feels complicated but can't cut it down. wants neutral term for kuldge

Nikita: no one will do on/off, will always be off

Holger: should not be easier or harder to switch on or off.

SteveN: what about may or may not in #3

Graham: explanation follows

Eric: what is the default? for backwards compatibility the default has
to be true

Nikita: TNC is a value of TM, losing ground by not
preserving. basenames are like primary keys in DB terms

Graham: value of basename is not its uniqueness

Nikita: basenames are used for addressing (with TNC)

Michel: mixed feelings, "looks rational, 1, 2, 3" understand here but
how to explain to others - #2 will trigger conflicts in companies,

Graham: already have options now

Eric: once lose control of TM, can't say what will happen

Sam: granularity case, when to turn on and off, do on a map wide basis
(rejects 3 and 4, but 4 most of all) would rather have just 1 and 2.

SteveN: lose 1 but put on #3

Lars: a lot of machinery, meaning of basename changes if TNC is on or
off (unique name versus a label) would prefer 4 and nothing
else. Wants a unique name, says it is a unique name, only applies to
variant names with TNC turned on -

SteveN: want to devalue unique identifier as name

Eliot: putting in variant name (Lars suggestion) too much abuse of
indirection

Michel agrees with Eliot on distinguishing element types, probably
need an optional element

Eliot: introduce new characteristic type "label" structurally
identical to basename but does not have TNC - (basename can have
types)

Lars: why not use type on basename to distinguish, does different
things from scope,

SteveN: defer this (6) to scope discussion

Nikita: if decide on type of basename, will need PSI

Holger: note that overide does not work on 5 and 6

Mary: label sounds like display name

Michel: have display name in HyTM, why not resurrect display name,
name with no constraint, was moved to variant set for processing,
should move back to the fore, reconcile HyTM and XTM.

Lars: label is display name by another name

Steve: does not agree at all, display name is data to be used for
display about a basename, whereas label does not have a relationship
to basename, display name is supposed to be an alternative. (HyTM,
display name defaults to the basename, when display name is absent)
uttering name gets you to the subject, not the view now.

Michel: fix is worse than the problem - will be too complex - if we
just drop TNC, problems might be worse.

SteveN: table this discussion and go onto scope.

Patrick: is this constraint in the sense of the discussion yesterday -

Mary: all agree on backwards compatible, agree on simplicity, is this
application specific?

Michel: starting to see it as application issue, merging operation is
more complex than merging names, like querying or constraint (SteveN
disagrees)

SteveN: merging has to do with what the syntax actually means - topic
- basename assertion type is in the reference model, TNC in the
standard now, so SAM defined in terms of RM must reflect the assertion
types in the RM

Holger: is it allowed in RM to have two topics with same name in the
same scope, if is allowed, means that model are processing.

SteveN: idea is, graph in RM terms two topics, with two assertions
that connect to one other topic, subject indicator of both of them,
but the semantics of the assertion requires that processing occur that
merge the two topics, can have it before or after

Lunch:

SteveN: scoping facility be used to control merging occurs from
perspective of a merge map (already a fact) and has been proposed that
particular scoping topics be used to indicate if TNC should be invoked
or not, also that typing mechanism (instance-of) to control TNC, need
to talk about scope, role in naming, and scope more generally

Eliot: scope is bogus

SteveN: has an attitude about scope, scope is a special case of more general

SteveN: empty set for scope

Nikita: should have implicit unrestrained scope

Sam: not sure saying nothing is the equivalent of saying empty set

SteveN: sets can be empty (so scope can still be set, even if empty)
why is it a problem to have an empty set for a scope

SteveN: scope is special case of more general phenomena

Topic<----------|------------>Topic
Subject of
this node is
relationship
between these two
|
|-assertion about this relationship (qualifies the other assoc.)
|
|
Node - set of subjects

scope is an assertion that qualifies another assertion, handle
assertion by saying there is an assertion type, scope operates by
taking a set of topics and associating them with the assertion being
qualified.

instance-of on occurrence, in the RM, what to do with the occurrence
(can use class and instance), qualifying it with class instance,

Lars: would not be say it is qualifying, but annotating

SteveN: Can have multiple scopes, can have a scope that is qualifed in
different ways, both of these are qualifications that could be avoided
in RM by typing of assertions, difference is that when qualifying, can
merge the different assertions, unlike typing, which would prevent
merging.

Graham: In SAM, a pointer to the set of topics for scope, SAM could
have PSIs so we can talk abut the associations.

Eliot: scope is a bad name, should be some other name, should say
scoping association

SteveN: when you have a set in the SAM, can you see it?

Michel: scope is overloaded, one is a namespace, valid role to play;
used to express a context, not necessarily

SteveN: if use scope to estalish scope of occurrence and to establish
the scope of a an assertion.

Michel using namespace in the sense of names, occurrences and
assertions.

Michel: need more assertion types to do scoping

Eliot: can always create a name to represent the namespace in which
that name is valid.

Lars: have had scope for a long time but have not considered its
operation in the standard

SteveN: attitude about scope, did not understand until Graham said
scope was bogus, not sure if we want to make scope determinate, how
simple and how limited do we want to make it, want to optimize for
success, scope has nothing locked down, do we want to lock it down?

SteveN: should not be locked down, reason, there are lots of ways to
qualify assertions, whole business about structured scopes, create all
the modifying assertions you want, can structure as much as you
want. Scope is easy and quick, default way of qualifying an assertion,
any way that you want. let scope be the mess that it is, if you want
more inference, make the assertions you want

Eliot: requires a second specification to lock down things left
undefined, leads to more than one way to solve a problem, hard to
determine if a problem can be solved and how to do it

Graham: can't get around it, even if take away scope, can give guidance

Eliot: need to establish conventions for use (either implementors,
developers or standards folks)

Michel: vendors can provide tools that are compatible with the
standard, same problem as with tables in SGML/XML, should allow
applications to make choices, concern should be to make practices not
be incompatible, but not more than that

Eliot: need a starter set to common problems, difficult for people to
step up to using topic maps, first barrier to usage is someone saying
topic maps are better to a particular problems

Lars: structure in scope is too far, leaving it undefined is not
enough, scope is all subjects, unconstrained scope is the empty set,
drop the structure, try to define what applies, validity, user context

SteveN: all subjects doctrine: would it ever be true to consider
subjects separate from any of the others,

Lars: all subjects - opinion occurrence any subject holds for Lars and the date

SteveN: two topic maps - two assertions in two different scopes -

Lars: does the standard say the intersection is in all scopes or in
any scope, has consequency for redundancy

SteveN: if no redundancy rules, then Steve's example holds

Holger: if up to application, then can use any or all at the choice of
the application,

Graham: not saying anything about the qualification of other
assertions, but acts differently for name (if using TNC)

SteveN: two independent topic maps, same assertion, different scopes,
want to get same assertion, but want to make sure don't tweak the
scopes

SteveN: reason why all is correct, preserves integrity of what was
said, compared not interpretated

Holger: for comparing two scope sets, look at all the scopes

SteveN: can't constrain scope and how it is used. preservation is more
important

SteveN: with TNC, when two topics collide, add banana to it

Graham: now agrees with SteveN

SteveN: why Lars should love this idea, b/c it makes it easy for
people to make topic maps, Lars objects to TNC b/c it makes topic maps
hard, need to be default assertion modifying assertion type, needed to
make topic maps practical

Eric: scope is all scopes in the rag-bag

Consensus: A scope consists of a set of subjects. Two sets are the
same set if they have all the same subjects.

Eric: scope is a mailbox, just a slot (not a way to make assertions),
almost a best practice sort of thing

Graham:

rfn('graham')=> #1

rfn('graham', 'd2002-08-07')=>#1

where

#1 {prop-scope, opinion,
[[Scope is bogus]] /
graham d2002-08-07}

problem is at the level of TMQL (Graham)

SteveN: allows people to express what they want and to query any way
the user wants to later.

Sam: lets allow abuse to happen in scope.

Mary: topic maps are not a panacena for all knowledge management -
like to have definition for scope, strict rules for scope,

Michel: can choose a product based on scope rules

Graham: two levels of scope, have defined two things, it is a set and
set equality applies. scope is also being used to make assertions
without being more specific

Sam: don't have enough information to make an assertion but do want to
put the rag on it.

Lars: know what will happen structurally, question is still open about
use of scope

Graham: scope creates assertions about topics

Mary: consult with other parties

Agenda for Monday:

Reconvene Monday at 9:00 AM

ISO SC34/WG3 - 5 August 2002

Ann

Bernard

Graham

Eliot

Lars

Eric

Michel

SteveN

Mary

Holger

Sam

Patrick

Jim

Scope discussion continued:

Sam: subject plays scope role in assertion, plays set role in
assertion, what kind of assertions are being made about that node,
nature of set, interpret as all, or as any, or fuffy, or match, goodto
make many assertions, Lars wants nature of set to be all. Lars is
doing standard application. (application layer) RM lets 100 flowers
blossom. node -> x-node plays scope role in AP scope assertion and
plays set role in AP association

SteveN:

interpretation matching (possibly for merging)

X ALL

Any

Should not have a X in the box for interpretation,

Lars thinks left hand check determines where the check goes on the
right hand side.

Interpretation based on membership in a scope set is bogus

Eliot: cannot make inference based on membership in scope set

Lars: if that is true, then make inference from a topic map is bogus

Eliot: has been working on automatic inference using topic maps, not
enough information in TM standard to do inference, can add types to
use in making inferences

Michel: should not go to that area

Eliot: not qualified to make a standard for inference

Ann: need to distinguish inference from computation, Ex. of computation ***

Eliot: can define types to characterize topic map components for
associations, names, on which to base inference, otherwise don't have
enough to do inference. by definition, in the application domain

Graham: agrees completely

Lars: wants to table

Ann: need a simple solution now, scope has a considerable amount of structure,

Eric: can we do TNC with just the one check? Yes

TNC:

Eric/Graham: optional in RM

Graham: typing on names was one suggestion, types on names indicates
if it was made with assumption of the TNC, backwards compatibility
requires default to be yes

Ann: TM where want to guard some topics from merging but not all,
another case, interoperations between domains, want merger but have
independently adopted the same name for some topics, not sufficiently
flexible enough to meet that case.

Lars: have agreed it to be optional

Graham: have options on mergemap rule, may not be granular enough

Lars: if have map authored without TNC, and then used with TNC, it will break

Eric: once released, TM may die or explode

Michel: sometimes may need authorization to merge, $$$, security,
etc. imp. to put the syntax at the right place for implementation

SteveN: contra Michel, Ann's proposal separates responsibility from
authority, cannot do that. when someone says merge, they must be the
responsible party, cannot separate them from the authority to do it

Ann: not saying they should be separated,

Michel: merge on several characteristics but not others, can see
topics but not occurrences, don't have a mechanism to do this, TNC may
be one case of this senario

Bernard: TM now has no antibody syntax, but this is application layer,

Michel: Proposal on syntax - put attribute on basename, (yes,no) (in
SGML terms) #3 from yesterday

(from yesterday)

1. Add property to TopicMap element

property 'tncRule' values (true| false) implies that all names within
this topicmap and any merged maps are bound, or not, by the TNC.
(unless overidden, default is yes)

SteveN: combine 1 and 2, what is left out?

Graham: not enough, wants more granularity, writing a single map

SteveN: talking about #2

Ann: but merger creates a third TM

4. Add 'tncRule' property to VariantName to allow authors to specify
if this VariantName should be bound by the TNC.

5. introduce new characteristic type "label" structurally identical to
basename but does not have TNC

6. basename can have types

Ann: are we discussing multiple ways to combine topicmaps?

Michel: should only do this type of merger now

Author

TNC - Y X

TNC - N X

On the basename of a topic, turn it on or off

All agree to on or off.

Now level of granularity for on or off.

Basename: TNC on or off (YES) in the SAM

TM level: TNC on or off

SteveN: is new basename rule syntax or SAM?

Lars: could use PSI in scope for TNC or add types to names; if use
type then turning on or off at TM level would not make sense

Michel: need to not be extremely pure so use will be easier, types on
names will reduce interchange of topic maps

SteveN: TNC names are a different type of names from other names,
share other things in common, strings, context free, important to
distinguish, but to say in SAM property is on or off, is
inappropriate, but issue of name type (first/last) is orthogonal to
the issue of whether TNC applies or not, would not want to mix up name
types with TNC or not TNC, in SAM, proposes it to be a different
animal

Graham: just subclass the name class structure, (Lars, yes/no is better than that suggestion)

Eric: are we meeting past noon?

Do we need to worry about TNC (on/off) in the SAM? Answer: NO!

Graham: how to represent TNC (on/off) in the SAM?

Options:

1. add property on/off onto basename item

2. subtype basename item (into label and into identifier (carries
connotation of uniqueness))

3. do it with scope

4. reify the name and create association

5. add type to names and have special type that indicates a name is unique

Graham: 2 is about different data model in the SAM, 5 is about using
TM contstructs to explain the model

Pro/Con 1:

Lars: yes/no very ugly; changes the semantics, really a different kind
of thing

Eliot: choice 1 is less bad in the syntax

#1 is dead.

#2 Pro/con

subtype basename item (into label and into identifier (carries
connotation of uniqueness))

Lars: adds complications to model

Graham: clarifies the complicated model

Ann: most in spirit with the model

Graham: if something is in the model, don't use the structures in the
model to build the model

#3. do it with scope

Eliot: overloads scope (ditto Holger, Lars)

Abuses semantics of scope

SteveN: interferes with authors using scope

Lars: Pro - can do it with no change, breakage zero

Graham: impact is zero on the model, will have to have a section on doing this

#3 - dies.

4. reify the name and create association

Pro/Con

Lars: too heavy, scaling, processing, syntactically,

Graham: elegant, using existing structures

#4 - dies.

5. add type to names and have special type that indicates a name is unique

Lars: makes SteveN unhappy

SteveN: orthogonal to happiness, and to name types

Lars: may want to have specialized types of unique names (identifiers)

Eliot: what is the case for disallowing name types

Lars: want to say webpage is bio and cv, for occurrences, need types
for topics - different relationships

Eliot: not object of two different classes but needs two interfaces, wants a name that is or is not unique name and another name.

Michel: why specialized types of identifiers

Lars: instance-of and scope have different semantics, B&W photos,
should not use scope, particular type of portrait, super/sub assoc.

Graham: type names are not the way to solve this problem, b/c of
inheritance of types, should be separate issue

#5 - dies.

#2 - the lone suvivor

subtype basename item (into label and into identifier (carries
connotation of uniqueness))

Syntax for basename:

1. attribute on basename element

value is: identifier/label - default identifier

value is: merge = on/off - default on

Pro/con:

Lars: attribute to change semantic of the element

Eliot: easy to do

Lars: impact is minimal on existing syntax

Michel: easy to understand

#1 - sick.

2. new element type - called "label"

Eliot: all the pros of one but not the cons

Lars: complicates the syntax, split goes higher up in the tree

Michel: when exchange TM will be indecipherable

Eliot: what is the difference in label and basename

Eliot: use basename, identifier, and label and deprecate basename

Ann: likes Eliot's suggestion, understanding had improved, divides
basename into identifier and label

Eliot: could apply to baseNameString as well.

#2 - ailing.

3. subelement of basename - switch (equivalent to attribute)

Graham: has all the bad of one plus

#3 - dies

4. instead of baseNameString could have label

Lars: open question does the problem one apply here (SteveN, problem
with 2 applies here) - does this change semantic of the element

Eliot: baseNameString never had the semantic identifier

Graham: applies elsewhere in the SAM

Lars: gave him a good idea, implies death of baseNameString

Ann: semantics of label - unique? what are the semantics of label

Eliot: human readable string to distinguish topics, not bound by TNC
and merging rules

Lars: use for display purposes

Ann: want to use label for luggage

Michel: problem with new element type, not self explanatory, for TM to
be used, if purpose of baseNameString vs label is merger

Lars: less important to be clear to users

Graham: will probably have to reach mergemap, should there be symmetry
on mergemap

Eliot: element is better than attribute, but Michel is correct, needs
to understand identifiers in merger, question is do we prefer clarity
over purity of design

Ann: option should be documented. should get National bodies to voice opinions

Lars: depend on brokeness of XML if an attribute value

Eliot: 2 and 4 don't matter.

SteveN: attribute on baseNameString element.

Ann: concerned about specifying constraints on operations on topic maps

Graham: included in the SAM

Text to National Bodies:

Attribute on baseNameString element, merge = on/off default on (XTM syntax)

MergeMap:

Eric: have 3 choices, overide other author merge on, overide other
author merge off, defer to incoming TM.

overide: make identifier

overide: make it a label

Lars: turn all baseNames into identifiers, does not make sense,
results in a broken topicmap

Michel: not in applicaton where it needs to be correct, needs to find
information - needs to merge

Graham: Lars only likes the last option -

Lars: will break topic maps

Michel: standard allows people to merge

SteveN: allowing authors to say, when merging treat everything as
identifiers -

Ann: what about malicious topic map?

Lars: should not merge at all

SteveN: don't allow mergemap to overide author who is merging - want
power to prevent merging.

Eric: turn identifiers into labels or leave it alone

Eliot: need separate way to specify merger

Ann: have canonical merge - and leave other options

Lars: already in the standard

Ann: need to define very precisely what happens with TM merger

SteveN: someone may have a subject identity that is incorrect, and
don't want merger

Lars - leaves

Michel: if not PSI's -

MergeMap:

SteveN: wants to merge but turn that off

Graham: should remove property from mergemap

Eric: make the attribute applyTNCRule

Graham: saying it is of type label or identifiers and that fires the rule

Eric: in mergemap call it applyTNCRule

SteveN: nameMerging on/off (in mergemap)

Eric: if variantName merge comes into play, name may confuse

Michel: looks like TMCL issue

Eric: two options: weaken or loosen the original author -

Graham: agrees with Eric

Change identifiers to labels or go with original map (but not change
labels into identifiers)

Ann: use case to change labels into identifiers

SteveN: as specified or none

SteveN: mergemap is on document level

Ann: why to restrict creation of topic map by merger

Graham: authors of TM should be able to turn their labels into identifiers

Ann: constructing topic map under her control from others, can use
something outside the standard, mergemap

SteveN: can cause anything to merge, now saying they have to create
topic maps this way

Material for comment:

***Will float for comments***

overide other author merge on, overide other author merge off, defer
to incoming TM.

overide: make identifier

overide: make it a label

Michel: attribute nameMerging value as-specified, off-for-all, on-for-all

***end float***

Eliot: if embed topic map in a document, applies to all TMs in the
document, if use DTDs (due to inheritance of attibute values)

Michel: need to specify when using something that applies to a
particular syntax, like DTDs

SteveN: or require everything to be said everywhere

Eliot: should apply to the topicMap element as an attribute

Ann: how much need to be done, just put attributes on the baseNames

Ann: need a good TM syntax in DSDL

Next meeting in Baltimore (XML 2002)