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] |
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.
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.
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.
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:
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.
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:
The meeting concluded that this case was pathological, but not necessarily incorrect. No constraint for this case will be added to the model.
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.
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.
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:
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.
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 meeting concluded that having the empty string as a value is OK, while null is still not allowed.
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:
The meeting concluded that the term 'subject identity' is not needed, and can be dropped.
Is the term 'theme' useful, or best forgotten?
The following considerations were raised by the meeting:
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.
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.
Are topic characteristic assignments statements about the topics's subject, or about the topic?
The following considerations were raised by the meeting:
The meeting concluded that topic characteristic assignments were statements about the subject, not the topic. No decision was reached on the reification of topics.
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 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.
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.
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:
The meeting concluded that the SAM should not necessarily attempt to mirror the constraints implied by the XTM 1.0 DTD.
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:
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.
Should the standard retain the topic naming constraint?
The following considerations were raised by the meeting:
The following alternatives (not necessarily mutually exclusive) were considered:
Considerations:
Considerations:
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).
The following alternatives were considered:
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.
Should it become possible for the scopes of topic characteristic assignments to have internal structure?
The following considerations were raised by the meeting:
No specific conclusion was reached. National bodies are urged to read the discussion paper on this issue and provide comments on the issue.
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:
No specific conclusion was reached. National bodies are urged to read the discussion paper on this issue and provide comments on the issue.
No new issues were raised at the meeting.
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.
The next meeting of WG3 will be held in Baltimore, as a plenary SC34 meeting, in conjunction with the XML 2002 conference.
The meeting transcript below was written by Patrick Durusau.
<SC 34 WG3 Meeting, Montreal 3 August 2002> 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 <topicMap id="tm"> <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 <SC 34 WG3 Meeting, Montreal 4 August 2002> - 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 or 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) 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. 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 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 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)