ISO/IEC JTC 1/SC34 N0321


Information Technology --

Document Description and Processing Languages

Title: Report of May 2002 Meeting of ISO/IEC JTC1/SC34/WG3 in Barcelona
Source: SC34/WG3
Project: All SC34 Projects
Project editor: All SC34 Editors
Status: Recommendations of WG3 meeting in Barcelona
Date: 2002-05-22
Summary: Recommendations of WG3 meeting in Barcelona
Distribution: SC34 and Liaisons
Refer to:
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]

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]

Barcelona meeting of WG3

Meeting content

The authors of the Reference Model presented their work to date, and received feedback from the WG3 members at the meeting.

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


Should all types be called classes, all classes types, or should both terms be used? Which terms should be used where?

The following considerations were raised by the meeting:

  • It may be useful to have one formal term, and to reserve the other for informal uses, similar to the topic/subject distinction.
  • The HyTM syntax already uses the term "type".
  • On the other hand, the XTM PSIs use the term "class".
  • It was said that most often, "type" is intensional, while "class" is extensional. Given that topic maps are have an intensional flavour it may be appropriate to use this term.
  • One might define the terms to be equivalent. This precludes reserving one term for possible later use.

The meeting concluded that the term "type" should be chosen, and that the term "class" should be reserved for possible future use. This raised the issue of what to do about the PSIs defined by XTM, but that issue was deferred. (See below.)


Should we have the topic.[classes] property? It means either that classness cannot be scoped, or that classness has a double representation. The question is: is scoping of classness important? Does it cause problems for implementations and applications?

The meeting concluded that while scoping of class-instance relationships was uncommon it was useful, and to remove that possibility would mean changes to the model that would have undesirable side-effects for merging. It would also mean an undesirable break with backwards compatibility.

Based on this conclusion it was decided that the SAM should represent class-instance relationships using associations, and that the [classes] property on classes should be removed.


Should the UML diagrams be made normative?

The meeting decided that the UML diagrams should be made informative. The rationale was that a double representation using both information item specifications and UML diagrams meant risking inconsistencies between the two. Keeping only one as normative would resolve these. Also, the UML diagrams, if normative, might carry with them UML-related baggage that would be undesirable.


Do the 'linktrav' and 'listtrav' attributes of the HyTM syntax have model significance?

It was observed that these attributes were in HyTime only meant as suggestions for rendering, and so were not constraints. It was agreed that most likely the attributes would not be very useful, but that anyone who took the trouble of entering them in a HyTM document would most likely have wanted them to be retained.

The resolution was to use published subjects to retain this information. This was preferred, as it avoided having to modify the model in order to preserve the information.

The "association-traversal" issue is a duplicate of this issue.

Unresolved issues


The "topic-naming-constraint" issue was discussed, but the meeting found itself unable to resolve it. It was observed that removing the TNC would mean a break with backwards compatibility. It was further observed that a possible solution might be to switch the positions of base names and display names, but this was not accepted.

It was agreed to revisit this issue at the next face-to-face meeting of WG3.


The "prop-schema" issues was discussed, and the meeting discovered that its description in N0299 was inaccurate. Its description was therefore modified. Further, the underlying requirement was formulated as "After merging TMs that have constraints, it should be possible, for any given topic item, base name item, variant name item, and information resource used as an occurrence, to find the constraints that apply to it and where they came from. This applies only to the constraints that are part of the definition of the assertion type."

Two possible resolutions were suggested:

  • Leave this for TMCL to define.
  • Define a published subject association type that could be used to associate a topic representing the constraints with the relevant information item.


The "op-sorting" issue was discussed, and it was observed that different published subjects used in variant name scopes might have different sorting algorithms associated with them. Based on this observation, a number of possible resolutions were proposed:

  • To leave the existing PSI with no algorithm, but define a new published subject with an associated algorithm.
  • To attach an algorithm to the existing PSI, but allow those unhappy with that algorithm to define their own PSIs.
  • To do nothing, as those wanting specified algorithms could create their own PSIs.

New issues

Discussions at the meeting raised a number of new issues, which are described below.


Should base name items be merged, so that assertions made about one base name will also apply to all other base names that have the same identity? (This also applies to occurrences.)


Should it be possible to create topics that represent strings, and for it to be formally clear that these topics do represent particular strings? If so, how?


The scope of ISO 13250 is currently restricted to only defining the issues related to the interchange of topic map information. Should that scope be extended so that the standard can also cover application-internal issues?

Should the subject identifiers defined by XTM 1.0 be retained as they are, or should new equivalent ones be defined to replace the originals?


Where should the indicators for the subjects published in the new ISO 13250 be published?


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


Does the use of an element type derived from "topic" in a HyTM document imply a class-instance relationship? Does use of the mnemonic attributes imply such a relationship?


How are facets represented in the SAM?


How should values from infinite subject spaces be represented in topic maps?


The authors of N0298 were instructed to prepare a more formal and complete draft of the Reference Model for the consideration of the committee.

The authors of N0299 were instructed to continue their work on the Standard Application Model, and prepare a new draft for the next meeting of WG3.

Lars Marius Garshol was instructed to prepare a more extensive draft of the roadmap (N0278) for the consideration of the committee, as it was recognized that the existing roadmap does not serve its purpose as documentation of the goals of the topic maps process for outsiders to the committee. The intention is that this document will develop into a part 0 of the standard that explains its structure.

Next meeting

The next meeting of WG3 will be held in Montreal, in conjunction with the Extreme Markup 2002 conference.