[sc34wg3] Revision of N0321

26 May 2002 15:24:03 +0200

--=-=-=

At the closing plenary of SC34 some people expressed dissatisfaction
with the phrasing of part of what is now N0321, and we agreed to sort
this out on the mailing list before updating N0321 in the ISO registry.

An improved version is attached. The changes are:

 1) Text about the "topic-naming-constraint" issue modified as
    requested by SRN.

 2) Ditto for "strings-as-subjects".

 3) Text of "names-as-subjects" modified in accordance with 2).

 4) The text on "op-sorting" was added.

Do any of those present at the meeting want any further changes, or
can I send this to Jim as the new version? Please respond with a
yes/no if you were at the meeting.

(Note for next time: compose this text on-the-fly on the projector so
that everyone can see the text and approve it as we go. To do so would
have improved the quality of the meeting, as well as of the output, I
think.)

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >

--=-=-=
Content-Type: text/html
Content-Disposition: attachment; filename=recommendations.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>ISO/IEC JTC 1/SC34 N321</title>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<style type="text/css">
th {
  text-align: left;
  vertical-align: top;
}

h1, h2, h3, h4 {
  font-family: Verdana, Helvetica, sans-serif;
}

body {
  margin-left: 10%;
  margin-right: 10%;
  margin-top: 48pt;
}

dt {
  font-weight: bold;
}

blockquote {
  color: #555;
}
</style>
</head>
<body>

<H2 ALIGN="RIGHT">ISO/IEC JTC 1/SC34 <FONT SIZE="+2">N0321</FONT></H2>
<IMG SRC="isoiec.gif" WIDTH="130" HEIGHT="56"> 
<H2>ISO/IEC JTC 1/SC34</H2> 
<H2>Information Technology --</H2> 
<H2>Document Description and Processing Languages</H2> 
<TABLE> 
<TR> 
  <TD VALIGN="TOP"><B>Title:</B></TD> 
  <TD>Report of May 2002 Meeting of ISO/IEC JTC1/SC34/WG3 in Barcelona</TD> 
</TR> 
<TR> 
  <TD VALIGN="TOP"><B>Source:</B></TD> 
  <TD>SC34/WG3</TD> 
</TR> 
<TR> 
  <TD VALIGN="TOP"><B>Project:</B></TD> 
  <TD>All SC34 Projects</TD> 
</TR> 
<TR> 
  <TD VALIGN="TOP"><B>Project editor:</B></TD> 
  <TD>All SC34 Editors</TD> 
</TR> 
<TR> 
  <TD VALIGN="TOP"><B>Status:</B></TD> 
  <TD>Recommendations of WG3 meeting in Barcelona</TD> 
</TR> 
<TR> 
  <TD VALIGN="TOP"><B>Action:</B></TD> 
  <TD></TD> 
</TR> 
<TR> 
  <TD VALIGN="TOP"><B>Date:</B></TD> 
  <TD>2002-05-22</TD> 
</TR> 
<TR> 
  <TD><B>Summary:</B></TD> 
  <TD>Recommendations of WG3 meeting in Barcelona</TD> 
</TR> 
<TR> 
  <TD VALIGN="TOP"><B>Distribution:</B></TD> 
  <TD>SC34 and Liaisons</TD> 
</TR> 
<TR> 
  <TD VALIGN="TOP"><B>Refer to:</B></TD> 
  <TD></TD> 
</TR> 
<TR> 
  <TD><B>Supercedes:</B></TD> 
  <TD></TD> 
</TR> 
<TR> 
  <TD VALIGN="TOP"><B>Reply to:</B></TD> 
  <TD>Dr. James David Mason <BR> (ISO/IEC JTC1/SC34 Chairman) <BR> Y-12
	 National Security Complex<BR> Information Technology Services<BR> Bldg. 9113
	 M.S. 8208<BR> Oak Ridge, TN 37831-8208 U.S.A.<BR> Telephone: +1 865
	 574-6973<BR> Facsimile: +1 865 574-1896<BR>E-mailk:
	 <A HREF="mailto:mxm@y12.doe.gov">mailto:mxm@y12.doe.gov</A><BR><A
	 HREF="http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm">http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm</A><BR><BR>
	 Ms. Sara Hafele, ISO/IEC JTC 1/SC 34 Secretariat<BR> American National
	 Standards Institute<BR> 25 West 43rd Street<BR> New York, NY 10036<BR> Tel: +1
	 212 642-4937<BR> Fax: +1 212 840-2298<BR> E-mail:
	 <A HREF="mailto:shafele@ansi.org">shafele@ansi.org</A> </TD> 
</TR> 
</TABLE> 

<h1>Barcelona meeting of WG3</h1>

<h2>Meeting content</h2>

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.

<h2>Resolved issues</h2>

<h3><a href="http://www.y12.doe.gov/sgml/sc34/document/0299.htm#type-vs-class" name="type-vs-class">type-vs-class</a></h3>

<blockquote>
Should all types be called classes, all classes types, or should both
terms be used? Which terms should be used where?
</blockquote>

<p>
The following considerations were raised by the meeting:
</p>

<ul>
<li>It may be useful to have one formal term, and to reserve the other
for informal uses, similar to the topic/subject distinction.</li>

<li>The HyTM syntax already uses the term "type".</li>

<li>On the other hand, the XTM PSIs use the term "class".</li>

<li>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.</li>

<li>One might define the terms to be equivalent. This precludes
reserving one term for possible later use.</li>
</ul>

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 <a href="#psi-topicmaps.org">below</a>.)

<h3><a href="http://www.y12.doe.gov/sgml/sc34/document/0299.htm#prop-classes"
name="prop-classes">prop-classes</a></h3>

<blockquote>
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?
</blockquote>

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.

<h3><a
href="http://www.y12.doe.gov/sgml/sc34/document/0299.htm#meta-uml-normative"
name="meta-uml-normative">meta-uml-normative</a></h3>

<blockquote>
Should the UML diagrams be made normative?
</blockquote>

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.

<h3><a
href="http://www.y12.doe.gov/sgml/sc34/document/0299.htm#occurrence-traversal"
name="occurrence-traversal">occurrence-traversal</a></h3>

<blockquote>
Do the 'linktrav' and 'listtrav' attributes of the HyTM syntax have
model significance?
</blockquote>

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.

<h2>Unresolved issues</h2>

<h3><a name="topic-naming-constraint" href="http://www.y12.doe.gov/sgml/sc34/document/0299.htm#topic-naming-constraint">topic-naming-constraint</a></h3>

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.

<h3><a name="prop-schema" href="http://www.y12.doe.gov/sgml/sc34/document/0299.htm#prop-schema">prop-schema</a></h3>

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

<p>
Two possible resolutions were suggested:
</p>

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

<h3><a name="op-sorting" href="http://www.y12.doe.gov/sgml/sc34/document/0299.htm#op-sorting">op-sorting</a></h3>

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:

<ul>
<li>To leave the existing PSI with no algorithm, but define a new
published subject with an associated algorithm.</li>

<li>To attach an algorithm to the existing PSI, but allow those
unhappy with that algorithm to define their own PSIs.</li>

<li>To do nothing, as those wanting specified algorithms could create
their own PSIs.</li>
</ul>

<h2>New issues</h2>

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

<h3><a name="names-as-subjects">names-as-subjects</a></h3>

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

<h3><a name="strings-as-subjects">strings-as-subjects</a></h3>

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?

<h3><a name="scope-extension">scope-extension</a></h3>

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?

<h3><a name="psi-topicmaps.org">psi-topicmaps.org</a></h3>

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?

<h3><a name="psi-publishing">psi-publishing</a></h3>

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

<h3><a name="prop-scope-structure">prop-scope-structure</a></h3>

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

<h3><a name="hytm-gi-significance">hytm-gi-significance</a></h3>

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?

<h3><a name="hytm-facet-representation">hytm-facet-representation</a></h3>

How are facets represented in the SAM?

<h3><a name="infinite-subject-spaces">infinite-subject-spaces</a></h3>

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

<h2>Instructions</h2>

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.

<h2>Next meeting</h2>

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

</body>
</html>
--=-=-=--