ISO/IEC JTC 1/SC34 N0321

ISO/IEC JTC 1/SC34

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
Action:
Date:	2002-05-22
Summary:	Recommendations of WG3 meeting in Barcelona
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]

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

type-vs-class

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.)

prop-classes

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.

meta-uml-normative

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.

occurrence-traversal

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

topic-naming-constraint

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.

prop-schema

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.

op-sorting

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.

names-as-subjects

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.)

strings-as-subjects

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?

scope-extension

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?

psi-topicmaps.org

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?

psi-publishing

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

prop-scope-structure

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

hytm-gi-significance

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?

hytm-facet-representation

How are facets represented in the SAM?

infinite-subject-spaces

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

Instructions

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.