[sc34wg3] SC34/WG3 Draft Minutes: 7 November 2002
Patrick Durusau
sc34wg3@isotopicmaps.org
Sat, 07 Dec 2002 18:25:23 -0500
This is a multi-part message in MIME format.
--------------090301020001010108030408
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Greetings!
Draft, largely unedited minutes from today's meeting of SC34/WG3 are
attached.
Reached fewer issues today but the issues covered were some of the
harder ones. Glad to report that we made substantial progress on a
number of issues and everyone left in good spirits.
Please post comments to the list.
Patrick
--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
--------------090301020001010108030408
Content-Type: text/html; charset=us-ascii;
name="sc34_7Nov2002.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="sc34_7Nov2002.html"
<html>
<!--THIS FILE IS GENERATED FROM AN XML MASTER.
DO NOT EDIT-->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Draft Minutes: SC34/WG3 Meeting, Baltimore, 7 November 2002</title>
<link rel="stylesheet" type="text/css" href="/stylesheets/tei-oucs.css">
<meta name="DC.Title" content="Draft Minutes: SC34/WG3 Meeting, Baltimore, 7 November 2002">
</head>
<body><a name="TOP"></a><table class="header" width="100%">
<tr>
<td align="left">
<h1 class="maintitle">Draft Minutes: SC34/WG3 Meeting, Baltimore, 7 November 2002</h1>
</td>
</tr>
</table>
<hr>
<h2>Contents</h2>
<ul class="toc">
<li class="toc">1. <a class="toc" href="#body.1_div.1">SC34/WG3 Morning Session</a><ul class="toc">
<li class="toc">1.1. <a class="toc" href="#sc34_7Nov2002-div-d0e77">TMQL Report (N0249)</a></li>
<li class="toc">1.2. <a class="toc" href="#sc34_7Nov2002-div-d0e100">Principles of Revision of ISO 13250</a></li>
<li class="toc">1.3. <a class="toc" href="#sc34_7Nov2002-div-d0e131">TMCL</a></li>
</ul>
</li>
<li class="toc">2. <a class="toc" href="#body.1_div.2">SC34/WG3 Afternoon Session</a><ul class="toc">
<li class="toc">2.1. <a class="toc" href="#sc34_7Nov2002-div-d0e198">Topic Naming Constraint - Scope</a></li>
<li class="toc">2.2. <a class="toc" href="#sc34_7Nov2002-div-d0e223">names-with-types</a></li>
<li class="toc">2.3. <a class="toc" href="#sc34_7Nov2002-div-d0e237">constr-single-subject-address</a></li>
<li class="toc">2.4. <a class="toc" href="#sc34_7Nov2002-div-d0e251">prop-type-properties</a></li>
<li class="toc">2.5. <a class="toc" href="#sc34_7Nov2002-div-d0e265">psi-topicmaps.org</a></li>
</ul>
</li>
</ul>
<div class="teidiv">
<h2><a name="body.1_div.1"></a>1. SC34/WG3 Morning Session
</h2>
<p><b>Attendees</b></p>
<ul>
<li><a name="d0e42"></a>Steve Pepper
</li>
<li><a name="d0e45"></a>H. Holger Rath
</li>
<li><a name="d0e48"></a>Sung_Hyuk Kim
</li>
<li><a name="d0e51"></a>Soon_Bum Lim
</li>
<li><a name="d0e54"></a>Derek Millar
</li>
<li><a name="d0e57"></a>Mary Nishikawa
</li>
<li><a name="d0e60"></a>Patrick Durusau
</li>
<li><a name="d0e63"></a>Motomu Naito
</li>
<li><a name="d0e66"></a>Lars Marius Garshol
</li>
<li><a name="d0e69"></a>Jim Melton, Liason from SC32
</li>
<li><a name="d0e72"></a>Ann Wrightson
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="sc34_7Nov2002-div-d0e77"></a>1.1. TMQL Report (N0249)
</h3>
<p><a name="d0e82"></a>Holger Rath: Has been on hold waiting for the SAM. About to revisit the requirements since the SAM should appear next Spring
in London (XML Europe 2003). Listed existing TMQL languages. There is a mailing list for TMQL at Yahoo groups.
</p>
<p><a name="d0e85"></a>New capabilities for TMQL (Holger and Lars): Not one big thing, but separate parts. One module the query part, insert and
update part, may have something similar to XPath, could have TMPath (don't know if it should be part of TMQL or some other
separate part). Lars: lot of use to build topic map driven websites, with TMQL have a standard for queries, but could also
have TMSLT to shape the output part for the website. People not satisfied to just display name of the topic, string operations,
etc. to shape the results. Ann: Continuing UK concern, original 13250 aim to handle TM information embedded in documents.
Lars: still collecting use cases for TMQL. SteveP: should solicit proposals. Lars: should have a workshop, for presentation
of proposals at XML Europe 2002.
</p>
<p><a name="d0e88"></a>Jim Melton: Curious about relationship with XQuery, if represented in XML? XML are trees, topic maps are multi-dimensional
graphs, for which XQuery is a hack.
</p>
<p><a name="d0e91"></a><b>Instructions to Editors</b> Prepare for workshop XML Europe, produce new draft of the requirements and seek use cases. Proposals and Use Cases by March
17, 2003 submitted to the TMQL discussion group, http://groups.yahoo.com/group/tmql-wg or the editors (Lars Marius Garshol,
larsga@garshol.priv.no; H. Holger Rath, holger.rath@empolis.com)
</p>
<p><a name="d0e96"></a>Jim Melton leaves.
</p>
</div>
<div class="teidiv">
<h3><a name="sc34_7Nov2002-div-d0e100"></a>1.2. Principles of Revision of ISO 13250
</h3>
<p><a name="d0e104"></a>Jim Mason arrives.
</p>
<p><a name="d0e107"></a>Steve Peppers: several options for revising ISO 13250. Ann Wrightson, are you saying update the roadmap? Michel, need to find
a framework for the roadmap. Peppers, why are we doing this? Newcomb, can't we derive this from requirements for SAM and RM.
Lars, should we allow ourselves to add types to names, etc. Newcomb, how much are we going to put on the table? Mason, if
NP for new addition, revision, opens up, potentially, the entire standard, however, may be the most likely way to deal with
the issues before us, SAM and RM are rather large additions to the standard. Could go to a multi-part international standard.
Peppers, then talking about a revision. Michel, concerned to progress by steps to make the standard stronger, do not open
everything up for discussion. Michel, consider SAM and RM as additions. Mason, SAM and RM have no official status, spending
time on things not in our scope. Mary, need a certain formality to the proceedings. Peppers: don't have to give the impression
that everything is up for grabs. Formally speaking it is possible to comment on any part of ISO 133250. Need to make specific
what work is being undertaken. Mason: New Work Item proposal, has a list of documents to be considered. Reviews the NP document.
Michel: multi-part, will be a revision. Mason: but multi-part directs attention to the new parts. Ann: talking about national
body comments and not everyone possible. Michel: objects to use of "revision" while SAM and RM are not stable. Newcomb: Do
what is necessary to put everything on the table except the syntax. Peppers: thinks that is a great idea. Would be a sign
that it is not changing anything. Ann: put forth a new work item which is designed to contain the new stuff. Get a new number?
Peppers: but existing stuff needs to be changed.
</p>
<p><a name="d0e110"></a>Eric Freese arrives
</p>
<p><a name="d0e113"></a>Michel: default standard is XTM syntax. concentrate on preserving that syntax. is a revision in a sense. Lars: restatement
is the better term, people discover new concerns while using the standard. Mason: can as SC34, can reject a requested change.
Michel: need to preserve backwards compatibility but also not add features that present users would not have thought of with
the old standard. Pepper: should err on the side of restrictive. Sam, dare to do less. Lars, if going to do changes, need
to say so in advance and say so in advance. Now is the time to change and should make all the changes at one time. Michel,
might have to find new requirements from new implementations. Ann: only way to get stability for the syntax is to say we are
not going to change the XTM syntax and develop a new syntax. Lars: Roadmap is in part to allow different syntaxes. Peppers:
more of a restatement than a revision, start with HyTM and XTM. Ann: XTM should be kept but should not be in a position of
being guarded from development. Sam, have the restatement task and also have the review process every 5 years. Ann, have things
in the standard that were by ISO process, wants a successor to XTM syntax. Mason, Sam brought up the periodic review process,
out of our scope of thinking right now, won't be up until 2007. does not initiate the process.
</p>
<p><a name="d0e116"></a>Lars: there are some issues of XTM syntax as a result of the SAM.
</p>
<p><a name="d0e119"></a><b>Proposed action</b> This is a restatement of ISO13250 where we, 1. specify a data model (RM/XTM); 2. explain relationship between HyTM to XTM;
3. produce a canonicalization syntax to enable conformance testing; 4. fix bugs.
</p>
<p><a name="d0e124"></a>Will not change XTM or HyTM in ways that will render existing topic maps syntactically invalid.
</p>
<p><a name="d0e127"></a>Newcomb: would be a way to kill HyTM if no one wants to work on it. Peppers, would have to re-word the standard to use the
SAM. Ann: thinks the HyTM analysis would be very useful. Mary: is there an interest in HyTM, anyone using it. Peppers: encourage
people to bring news of use of HyTM.
</p>
</div>
<div class="teidiv">
<h3><a name="sc34_7Nov2002-div-d0e131"></a>1.3. TMCL
</h3>
<p><a name="d0e135"></a>Peppers: status, approved as new work item 19756, draft requirements from July, 2001, have a couple of submissions, Ontopia
is one of them, Peppers is project editor. Put on ice until progress on data model, since end of 2001. Is it time to go forward
with TMCL? Lars: don't have a satisfactory requirements document, long list of questions that have not been answered by that
document. soliciting use cases and proposals is premature. Newcomb: likes the division of XML documents from their DTDs, need
the DTD only if you want to validate, TMCL document should not be required know what a topic map means. Lars: unavoidable
that the schema will do more than just constrain, because presence of constraints provide information. Peppers: Issue of modularization
is important. Michel: with interchange, what is the meaning of TMCL, Holger: data typing Lars: examples, sorting by height
would be numbers.
</p>
<p><a name="d0e138"></a><b>Summary</b> Editor will be instructed to solicit input and prepare a revision of the requirements document.
</p>
<p><a name="d0e143"></a>Nikita arrived after the morning break
</p>
</div>
</div>
<div class="teidiv">
<h2><a name="body.1_div.2"></a>2. SC34/WG3 Afternoon Session
</h2>
<p><b>Attendees</b></p>
<ul>
<li><a name="d0e158"></a>Steve Pepper
</li>
<li><a name="d0e161"></a>H. Holger Rath
</li>
<li><a name="d0e164"></a>Sung_Hyuk Kim
</li>
<li><a name="d0e167"></a>Soon_Bum Lim
</li>
<li><a name="d0e170"></a>Derek Millar
</li>
<li><a name="d0e173"></a>Mary Nishikawa
</li>
<li><a name="d0e176"></a>Patrick Durusau
</li>
<li><a name="d0e179"></a>Motomu Naito
</li>
<li><a name="d0e182"></a>Lars Marius Garshol
</li>
<li><a name="d0e185"></a>Ann Wrightson
</li>
<li><a name="d0e188"></a>Nikita
</li>
<li><a name="d0e191"></a>Eric Freese
</li>
<li><a name="d0e194"></a>Jim Mason
</li>
</ul>
<p></p>
<div class="teidiv">
<h3><a name="sc34_7Nov2002-div-d0e198"></a>2.1. Topic Naming Constraint - Scope
</h3>
<p><a name="d0e203"></a>Comments from Japan: Mary, don't use baseName for TNC. Should define an element for a name that has TNC apply to it. Objections
were to the changes in the syntax and want a new element type. UK: Ann, should retain TNC but should be optional. Norway:
Steve, saw it as meeting in Montreal reached five conclusions. 1. should be optional. 2. topic map authors should be able
to indicate when TNC applies. 3. should be done at baseName level 4. should use an attribute of merge on or off 5. in SAM,
if label not subject to TNC, if identifier, it is subject to TNC. Reviewed Montreal and decided only the first one was acceptable.
allowing authors to specify whether TNC applies, if at individual baseName string, can create confusion sees it as a conflict.
Newcomb: disagrees whether there is a conflict. Lars: generally happy with Montreal. Peppers: not happy at all. should be
at the level of application where merging. standard should define one form of merging and allow others. Lars: the TNC in 13250
and XTM qualifies as a bug, machinery to make it optional is bug enhancement, use unambiguous property, TMCL should be able
to declare rules for merging on whatever characteristics. mistake to do this with baseNames in scope. Leaves issue with theoretical
topic maps that use TNC to establish identity, use TMCL to specify the merging rules. Michel: may be a good thing to have,
cleanest thing to have is to stick with subject identity as the place to put merging stuff. Newcomb: do we want to address
topics by names alone? Ann: yes, wants to use controlled vocabulary for addressing topics. Peppers: scope interferes with
other things, must specify the scope before uttering the name. in practice utter the name and then choose from a short list.
namespace aspect of scope creates conflicts. scoped by name of composer since two names are the same. Sam: seems odd vehement
agreement that scope is overloaded, so why not fix that. Lars: scope is overloaded because baseName does not have types, the
real problem is the TNC. wants a core set of merging rules, does destroy addressing topics by name, who needs to address topic
by their names, Mary: real control vocabularies that are being developed by different groups in two different companies, Asia
is different in different companies. must be one method of assigning identity in the company. Michel: company with many different
departments so can scope but then need to merge. Newcomb: instead of merging to have two names in the same scope it is an
error instead of merging. Wants to preserve ability to address topics by name. Lars: difficult to be sure that two topic are
in the same scope and want them to remain distinct, why is it important to address topics by its name, and why do you want
it. Michel: can create namespace by using topic types or by roles. address by name, the usual way to address things is by
name, used in natural language processing Newcomb: many companies have controlled vocabularies, reason for them is to address
by name Newcomb: need to support controlled vocabularies, such as the Library of Congress. Mikita: should be able to do scope
with association. difficult to use associations for this. Holger: to address a topic, use name in a certain namespace, rather
address something by its identity, request something by its name, query to find something, should take TNC away and support
for all characteristics. Sam: people will want to address things by their names. Lars: between end user and the standard,
use TMCL. Mary: wants to address with a controlled vocabularies, the purpose of the name is not for identity in their vocabulary,
should not use names as identifiers. Peppers: two requirements, author says this is name in a namespace, and to support homynyms.
can we tie this into typed-names issue for the SAM, Ann: two related things, points at the illusion of topic maps, a subject
that can be identified, by some means other than a name, remember started where knew topics should merge go together. Newcomb:
thinks identifiers are the same thing as names, arguing for unique identifier be preserved, critical feature to have unambiguous
addressing. add types to names, would get what he wants. Could do the same thing with scope. Sam: type proposal is limited
to single instance-of. Michel: does not understand.
</p>
<p><a name="d0e206"></a><b>Proposed solution</b>
<pre>
<topic id="EKN-foo">
<baseName>
<instanceOf><topicRef xlink:href="#ENK"/></instanceOf>
<baseNameString>foo</baseNameString>
</baseName>
</topic>
should only allow one instanceOf and would allow it to have scope.
<topic id="EKN">
<instanceOf>
<subjectIndicatorRef href="http://[PSI for controlled vocabulary or unique property]"/>
</instanceOf>
...
</topic>
</pre>
</p>
<p><a name="d0e214"></a>Lars: doesn't this create a uniqueness rule in prose rather than in TMCL. Mary: works for Newcomb and she can just ignore
it. Holger: how to define when merging happens. Mary: how to use scope, would not be used to disambiguate names. Holger: what
is the meaning if instanceOf is not in the baseName, if not there. Lars: will say what he does not like in writing, can't
merge two foos if in same scope. Michel: not sure instanceOf is a good name. Holger: what is the influence of baseName instanceOf
on variantName, may be redundant to TMCL, Peppers: need to offer guidance on usage
</p>
<p><a name="d0e217"></a><b>Proposed Resolution</b> see solution above.
</p>
</div>
<div class="teidiv">
<h3><a name="sc34_7Nov2002-div-d0e223"></a>2.2. names-with-types
</h3>
<p><a name="d0e228"></a>Done.
</p>
<p><a name="d0e231"></a><b>Proposed Resolution</b> Solution to TNC resolved this issue
</p>
</div>
<div class="teidiv">
<h3><a name="sc34_7Nov2002-div-d0e237"></a>2.3. constr-single-subject-address
</h3>
<p><a name="d0e242"></a>In the SAM, when merge topics, both have subject addresses and they are different, get an error. What happens when the single
subject address constraint is violated?
</p>
<p><a name="d0e245"></a><b>Proposed Resolution</b> Defer
</p>
</div>
<div class="teidiv">
<h3><a name="sc34_7Nov2002-div-d0e251"></a>2.4. prop-type-properties
</h3>
<p><a name="d0e256"></a>Should we name the type properties [association type], [role type], and [occurrence type], or should they all be called [type].
Peppers, owner of the type qualifies the type.
</p>
<p><a name="d0e259"></a><b>Proposed Resolution</b> Use type until a need shown for more specific terms.
</p>
</div>
<div class="teidiv">
<h3><a name="sc34_7Nov2002-div-d0e265"></a>2.5. psi-topicmaps.org
</h3>
<p><a name="d0e270"></a>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? Newcomb, not happy with what we have, OASIS should provide a space for this. Standard should support PSI within
itself. May be a use case for URN's. Lars: need to have someone go away and find a solution. Peppers: what is status of topicmaps.org.
could transfer to ISUG. Mason: public text in SGML, Lars: gives a way to use URN's and something else. IETF has issued specs
on resolving URN's. Michel: will need to keep old PSI's along with the new. Peppers: bigger problem with language and country
codes, will have to re-write the PSI's. Could have a topic map with 8 topics that merges to support the PSI's
</p>
<p><a name="d0e273"></a>Bernard arrives.
</p>
<p><a name="d0e276"></a><b>Proposed Resolution</b> New subject identifiers, domain (topicmaps.org) owned by ISUG, for all XTM PSI's except topic, association and occurrence,
to conform to OASIS PSI TC recommendations.
</p>
</div>
</div>
<hr>
<div class="footer">Comments should be directed to the topic map list, <a href="mailto:sc34wg3@isotopicmaps.org">sc34wg3@isotopicmaps.org</a>. Corrections should be send to <a href="mailto:pdurusau@emory.edu">Patrick Durusau, pdurusau@emory.edu</a></div>
</body>
</html>
--------------090301020001010108030408--