[sc34wg3] Baltimore Minutes Attached!
Patrick Durusau
sc34wg3@isotopicmaps.org
Tue, 07 Jan 2003 07:16:28 -0500
This is a multi-part message in MIME format.
--------------050505010100050908000201
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Greetings!
A sleepy workaholic failed to attach the draft minutes! Sorry 'bout that!
Patrick
--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
--------------050505010100050908000201
Content-Type: text/html; charset=us-ascii;
name="SC34_6-9Dec2002.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="SC34_6-9Dec2002.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>SC34 Meeting, Baltimore, 6-9 December 2002</title>
<link rel="stylesheet" type="text/css" href="/stylesheets/tei-oucs.css">
</head>
<body><a name="TOP"></a><table class="header" width="100%">
<tr>
<td align="left">
<h1 class="maintitle">Draft Minutes: SC34 Meeting, Baltimore, 6-9 December 2002</h1>
</td>
</tr>
</table>
<hr>
<h2>Contents</h2>
<ul class="toc">
<li class="toc">1. <a class="toc" href="#body.1_div.1">6 December 2002: SC34/WG8 Morning Session</a><ul class="toc">
<li class="toc">1.1. <a class="toc" href="#SC34_6-9Dec2002-div-d0e80">Subject and Resource</a></li>
<li class="toc">1.2. <a class="toc" href="#SC34_6-9Dec2002-div-d0e99">Dependencies on RDF</a></li>
<li class="toc">1.3. <a class="toc" href="#SC34_6-9Dec2002-div-d0e109">Reifiers and Merging</a></li>
<li class="toc">1.4. <a class="toc" href="#SC34_6-9Dec2002-div-d0e125">merge-srcloc-vs-subject 4.1 Merging Topics</a></li>
<li class="toc">1.5. <a class="toc" href="#SC34_6-9Dec2002-div-d0e141">term-subject-def</a></li>
<li class="toc">1.6. <a class="toc" href="#SC34_6-9Dec2002-div-d0e154">prop-notation-interp</a></li>
<li class="toc">1.7. <a class="toc" href="#SC34_6-9Dec2002-div-d0e167">prop-reifier-topic</a></li>
<li class="toc">1.8. <a class="toc" href="#SC34_6-9Dec2002-div-d0e180">string-normalization</a></li>
<li class="toc">1.9. <a class="toc" href="#SC34_6-9Dec2002-div-d0e198">string-bidi</a></li>
<li class="toc">1.10. <a class="toc" href="#SC34_6-9Dec2002-div-d0e211">container-props</a></li>
<li class="toc">1.11. <a class="toc" href="#SC34_6-9Dec2002-div-d0e224">term-topic-characteristic-reified</a></li>
<li class="toc">1.12. <a class="toc" href="#SC34_6-9Dec2002-div-d0e237">subject-identity-established</a></li>
<li class="toc">1.13. <a class="toc" href="#SC34_6-9Dec2002-div-d0e250">prop-reifier-computed</a></li>
<li class="toc">1.14. <a class="toc" href="#SC34_6-9Dec2002-div-d0e263">prop-base-locator</a></li>
</ul>
</li>
<li class="toc">2. <a class="toc" href="#body.1_div.2">6 December 2002: SC34/WG3 Afternoon Session</a><ul class="toc">
<li class="toc">2.1. <a class="toc" href="#SC34_6-9Dec2002-div-d0e324">term-application</a></li>
<li class="toc">2.2. <a class="toc" href="#SC34_6-9Dec2002-div-d0e337">prop-srcloc-interchange</a></li>
<li class="toc">2.3. <a class="toc" href="#SC34_6-9Dec2002-div-d0e356">op-sorting</a></li>
<li class="toc">2.4. <a class="toc" href="#SC34_6-9Dec2002-div-d0e369">psi-display-name</a></li>
<li class="toc">2.5. <a class="toc" href="#SC34_6-9Dec2002-div-d0e382">merge-use-of-schemas</a></li>
<li class="toc">2.6. <a class="toc" href="#SC34_6-9Dec2002-div-d0e395">psi-subclassing-loops</a></li>
<li class="toc">2.7. <a class="toc" href="#SC34_6-9Dec2002-div-d0e408">locator-normalization</a></li>
<li class="toc">2.8. <a class="toc" href="#SC34_6-9Dec2002-div-d0e430">Agenda for tomorrow</a></li>
</ul>
</li>
<li class="toc">3. <a class="toc" href="#body.1_div.3">7 December 2002: SC34/WG3 Morning Session</a><ul class="toc">
<li class="toc">3.1. <a class="toc" href="#SC34_6-9Dec2002-div-d0e510">TMQL Report (N0249)</a></li>
<li class="toc">3.2. <a class="toc" href="#SC34_6-9Dec2002-div-d0e533">Principles of Revision of ISO 13250</a></li>
<li class="toc">3.3. <a class="toc" href="#SC34_6-9Dec2002-div-d0e564">TMCL</a></li>
</ul>
</li>
<li class="toc">4. <a class="toc" href="#body.1_div.4">7 December 2002: SC34/WG3 Afternoon Session</a><ul class="toc">
<li class="toc">4.1. <a class="toc" href="#SC34_6-9Dec2002-div-d0e631">Topic Naming Constraint - Scope</a></li>
<li class="toc">4.2. <a class="toc" href="#SC34_6-9Dec2002-div-d0e656">names-with-types</a></li>
<li class="toc">4.3. <a class="toc" href="#SC34_6-9Dec2002-div-d0e670">constr-single-subject-address</a></li>
<li class="toc">4.4. <a class="toc" href="#SC34_6-9Dec2002-div-d0e684">prop-type-properties</a></li>
<li class="toc">4.5. <a class="toc" href="#SC34_6-9Dec2002-div-d0e698">psi-topicmaps.org</a></li>
</ul>
</li>
<li class="toc">5. <a class="toc" href="#body.1_div.5">8 December 2002: SC34/WG3 Morning Session</a><ul class="toc">
<li class="toc">5.1. <a class="toc" href="#SC34_6-9Dec2002-div-d0e770">term-scope-def</a></li>
<li class="toc">5.2. <a class="toc" href="#SC34_6-9Dec2002-div-d0e898">prop-scope-structure</a></li>
<li class="toc">5.3. <a class="toc" href="#SC34_6-9Dec2002-div-d0e920">err-constraint-violations</a></li>
<li class="toc">5.4. <a class="toc" href="#SC34_6-9Dec2002-div-d0e948">op-modifications</a></li>
<li class="toc">5.5. <a class="toc" href="#SC34_6-9Dec2002-div-d0e958">reification-effects</a></li>
<li class="toc">5.6. <a class="toc" href="#SC34_6-9Dec2002-div-d0e992">term-equal</a></li>
</ul>
</li>
<li class="toc">6. <a class="toc" href="#body.1_div.6">8 December 2002: SC34/WG3 Afternoon Session</a><ul class="toc">
<li class="toc">6.1. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1063">Short Tour of Reference Model</a></li>
<li class="toc">6.2. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1081">term-subject-address-def</a></li>
<li class="toc">6.3. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1106">locator-reference</a></li>
<li class="toc">6.4. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1144">infinite-subject-spaces</a></li>
<li class="toc">6.5. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1193">strings-as-subjects</a></li>
<li class="toc">6.6. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1231">Future plans for SAM</a></li>
</ul>
</li>
<li class="toc">7. <a class="toc" href="#body.1_div.7">9 December 2002: SC34/WG3 Morning Session</a><ul class="toc">
<li class="toc">7.1. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1289">ISO-HTML</a></li>
<li class="toc">7.2. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1298">ISMID</a></li>
<li class="toc">7.3. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1306">HyTime</a></li>
<li class="toc">7.4. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1315">SMDL</a></li>
<li class="toc">7.5. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1323">Topic Map Reference Model</a></li>
</ul>
</li>
<li class="toc">8. <a class="toc" href="#body.1_div.8">9 December 2002: SC34/WG3 Afternoon Session</a><ul class="toc">
<li class="toc">8.1. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1457">Bernard Valant with Graph Theory</a></li>
<li class="toc">8.2. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1469">Newcomb on Roles</a></li>
<li class="toc">8.3. <a class="toc" href="#SC34_6-9Dec2002-div-d0e1484">Newcomb on SAM issues</a></li>
</ul>
</li>
</ul>
<div class="teidiv">
<h2><a name="body.1_div.1"></a>1. 6 December 2002: SC34/WG8 Morning Session
</h2>
<p><a name="d0e37"></a>CDROM with SC34 document archive, agenda and topic map of standards by Lars distributed.
</p>
<p><a name="d0e40"></a>Concentrate on SAM today and do requirements and constraint language on Saturday.
</p>
<p><b>Attendees:</b></p>
<ul>
<li><a name="d0e48"></a>Steve Pepper
</li>
<li><a name="d0e51"></a>H. Holger Rath
</li>
<li><a name="d0e54"></a>Sung_Hyuk Kim
</li>
<li><a name="d0e57"></a>Soon_Bum Lim
</li>
<li><a name="d0e60"></a>Derek Millar
</li>
<li><a name="d0e63"></a>Mary Nishikawa
</li>
<li><a name="d0e66"></a>Patrick Durusau
</li>
<li><a name="d0e69"></a>Eric Freese
</li>
<li><a name="d0e72"></a>Motomu Naito
</li>
<li><a name="d0e75"></a>Lars Marius Garshol
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e80"></a>1.1. Subject and Resource
</h3>
<p><a name="d0e85"></a><b>Issue:</b> Should a subject be the same as a resource in RDF?
</p>
<p><a name="d0e90"></a>RFC 2396 defines resource. "Can be anything that has identity..."
</p>
<p><a name="d0e93"></a><b>Proposed resolution:</b>Allow subject definition in the SAM as it is in 3.4. Not making an explicit reference to RDF.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e99"></a>1.2. Dependencies on RDF
</h3>
<p><a name="d0e103"></a><b>Proposed Resolution:</b> Do not have dependencies on RDF in the SAM
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e109"></a>1.3. Reifiers and Merging
</h3>
<p><a name="d0e113"></a>(Lars) Possible to have two topic items that reify the same topic. Nothing in standard now compells merger of those two topics.
</p>
<p><a name="d0e116"></a>Source locators keep track of what a topic has had and makes it possible to detect this condition.
</p>
<p><a name="d0e119"></a><b>Proposed Resolution</b>Two topic items that reify the same topic must merge.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e125"></a>1.4. merge-srcloc-vs-subject 4.1 Merging Topics
</h3>
<p><a name="d0e129"></a>(Lars) One topic B with a subject indicator that points to subject A. Is it a subjectindicatorRef or a srcloc (after merger)?
Three possible resolutions, 1. Make it subID, 2. make it srcloc, 3. let it be both. subjectIndicatorRef should be a topicRef.
if use a topicRef, ends up as srcloc. This means 2 and 3 would be the solutions. Lars, should go with #2. better to go with
topicRef. do it as srcloc.
</p>
<p><a name="d0e132"></a>(SteveP) Problem with #1 would be throwing out srcloc which is what happens when merging under other circumstances. No argument
for retaining subID after merger as it is self reference.
</p>
<p><a name="d0e135"></a><b>Proposed Resolution</b> Make the one that causes the merging into a srcloc.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e141"></a>1.5. term-subject-def
</h3>
<p><a name="d0e145"></a>Revised draft and replaced with examples, should we bring back longer definition of subject or leave as shorter?
</p>
<p><a name="d0e148"></a><b>Proposed Resolution</b> Take examples out and put in note (to avoid reliance on examples as limitation) Use Plato's example of the good as part of
the note.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e154"></a>1.6. prop-notation-interp
</h3>
<p><a name="d0e158"></a>When have locator item [notation] = "URI' [address]="http://www.somewhere.com"] standard says only one defined location syntax.
if use your own, must use x- prefix. Martin Bryan, suggested that IETF will be talking about International Resource indicators
(IRI) and need to add HyTime syntax. Do we need a mechanism for introducing new notations? Steve, do we actually need this?
Could make it a published subject.
</p>
<p><a name="d0e161"></a><b>Proposed Resolution</b> Adding new notations will require changes to syntax specifications, therefore, this issue is not the problem. Close and let
it be.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e167"></a>1.7. prop-reifier-topic
</h3>
<p><a name="d0e171"></a>Can reify anything except a topic. Not possible now because it implies merging. with subjectIndicatorRef to refer to the topic.
Using a resourceRef to address an Association (biggest outstanding issue).
</p>
<p><a name="d0e174"></a><b>Proposed Resolution</b> Should topic items have a reifier property and the answer is no. (Consistent with reification in general. See term-subject-address-def
for further discussion) Definition of reification needs to be revisited. 3.4.4
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e180"></a>1.8. string-normalization
</h3>
<p><a name="d0e184"></a>Japan's comments, more background needed. Section 2.1, issue related to string types. Matching of strings for merging. Text
says a string is sequence of Unicode characters. OK, but can be written in different ways. XML 1.1 says use Normalization
C. Lars, four choices, 1. NFC, 2. NFD, 3. Normalization and don't say which one, 4. Ignore the issue. current text says 3
but not which one. Export from C has benefits because it follows XML.
</p>
<p><a name="d0e187"></a><b>Proposed Resolution</b> Current text is fine, use normalization but don't say which one.
</p>
<p><a name="d0e192"></a><b>Amended Proposed Resolution</b> add that NFC normalization is required (following XML).
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e198"></a>1.9. string-bidi
</h3>
<p><a name="d0e202"></a>Only an issue with right to left script, Arabic, Hebrew. Could do this with 1. syntax, 2. scope, 3. follow Unicode with direction
characters.
</p>
<p><a name="d0e205"></a><b>Proposed Resoution</b> Text as it stands sufficient, defer to Unicode for bidi issues.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e211"></a>1.10. container-props
</h3>
<p><a name="d0e215"></a>Should we distinguish between properties that are containers and those that are references? Or let people work it out. Roles
on topics and roles on associations, both containment, but can't implement that way. Have role in two separate places. (Distinguish
between properties which have containment semantics, and those which are references?)
</p>
<p><a name="d0e218"></a><b>Proposed Resolution</b> Don't distinguish between these properties.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e224"></a>1.11. term-topic-characteristic-reified
</h3>
<p><a name="d0e228"></a>Is the thing reified by a topic a characteristic of it? Such as reifying a baseName, does the baseName become a characteristic?
Really in the subject world and not in the topic world. Not part of the topic map at all. What side of the fence does reification
fall? Lars, say it falls on the machinery side.
</p>
<p><a name="d0e231"></a><b>Proposed Resolution</b> The thing reified by a topic does not count as a characteristic of the topic. Standard stands as is.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e237"></a>1.12. subject-identity-established
</h3>
<p><a name="d0e241"></a>Martin Bryan - subject identity can be inferred? ISO 13250 states that subject identity may be "inferred from the topic's
characteristics." Does SAM need words to the same effect? Lars, a question of wording. SteveP, would you want to do merging
on something other than characteristics?
</p>
<p><a name="d0e244"></a><b>Proposed Resolution</b> Should work in ISO 13250 language on inference of subject identity into section 4.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e250"></a>1.13. prop-reifier-computed
</h3>
<p><a name="d0e254"></a>Some people are unhappy about this issue in the SAM. Graham Moore in particular.
</p>
<p><a name="d0e257"></a><b>Proposed Resolution</b> Current text is the solution.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e263"></a>1.14. prop-base-locator
</h3>
<p><a name="d0e267"></a>Is a base locator property on the topic map item needed by other specifications? Was a way to locate a topic map. Kal and
Graham wanted it removed. Lars sees the following issue: composed-by($A, puccini) query, topic-ids, need locator for higher
level standards? base-locator and source-locator on topic map, no notes on Graham's objection
</p>
<p><a name="d0e270"></a><b>Proposed Resolution</b> Do need base-locator and source-locators.
</p>
</div>
</div>
<div class="teidiv">
<h2><a name="body.1_div.2"></a>2. 6 December 2002: SC34/WG3 Afternoon Session
</h2>
<p><b>Attendees:</b></p>
<ul>
<li><a name="d0e286"></a>Steve Pepper
</li>
<li><a name="d0e289"></a>H. Holger Rath
</li>
<li><a name="d0e292"></a>Sung_Hyuk Kim
</li>
<li><a name="d0e295"></a>Soon_Bum Lim
</li>
<li><a name="d0e298"></a>Derek Millar
</li>
<li><a name="d0e301"></a>Mary Nishikawa
</li>
<li><a name="d0e304"></a>Patrick Durusau
</li>
<li><a name="d0e307"></a>Eric Freese
</li>
<li><a name="d0e310"></a>Motomu Naito
</li>
<li><a name="d0e313"></a>Lars Marius Garshol
</li>
<li><a name="d0e316"></a>Steve Newcomb
</li>
<li><a name="d0e319"></a>Nikita Ogievetsky
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e324"></a>2.1. term-application
</h3>
<p><a name="d0e328"></a>Do we need to define the term "application" formally?
</p>
<p><a name="d0e331"></a><b>Proposed Resolution</b> No, current definition is sufficient.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e337"></a>2.2. prop-srcloc-interchange
</h3>
<p><a name="d0e341"></a>None of the interchange systaxes allow source locators to be interchanged. Is interchange of source locators a desired feature?
Do the syntaxes need to be extended to accomodate source locators?
</p>
<p><a name="d0e344"></a>Lars, to avoid round tripping, Steve does not see as pernicious, Lars does. SteveN, subjectIndicator that points at the topic
ID everytime it occurs. SteveN -> doesn't think we should worry about serialization, not in our scope, if we say what the
syntax means, that is enough, have provided for interchange. only concerned with what topic map means -> why would this standard
be concerned with conformance clause -> Holger -> to define conformance -> Lars -> look at XTM syntax -> conformance (section
4 of XTM) -> SteveN -> not proper requirement for conformance -> making assumption that is not correct -> must perform logical
equivalence testing to determine conformance -> dispute is about what is the canonical syntax to be used. Lars -> whole point
of canonical syntax arising from SAM, know what is logically significant or not.
</p>
<p><a name="d0e347"></a>Lars - <topic id="a"*gt; = both sourceloc and subjectid, whereas subjectIndicator = subjectID, question is do we need source
locators. Logical equivalent ignores subject locators. Holger -> if don't do serialization do we give enough guidance, Lars
-> wants to have an informative annex on serialization
</p>
<p><a name="d0e350"></a><b>Proposed Resolution</b> Don't have to preserve source locators for interchange.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e356"></a>2.3. op-sorting
</h3>
<p><a name="d0e360"></a>Does this standard need to define how sorting of topics is done? Is is a highly fundamental operation. On the other hand,
users may want flexibility in this regard.
</p>
<p><a name="d0e363"></a><b>Proposed Resolution</b> Default sort order is defined as Unicode code point order. (Need to modify string normalization order to require NFC, same
as XML)
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e369"></a>2.4. psi-display-name
</h3>
<p><a name="d0e373"></a>Is there any need for this as a PSI.
</p>
<p><a name="d0e376"></a><b>Proposed Resolution</b> Can be resolved by saying display name is needed in order to have non-textual display for topics. Means we will keep the
PSI and it is not simply for backwards compatibility. 5.3 remove last sentence of second paragraph, extend what is now the
last sentence: "...in context which are indicated by additional parameters on the variant name."
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e382"></a>2.5. merge-use-of-schemas
</h3>
<p><a name="d0e386"></a>The presence of a TMCL schema may allow applications to improve the result of merging topics/topic maps by providing enough
information to allow implementations to do additional transformations and reduncy removal. How should the SAM specification
deal with this possibility? Holger -> more of an issue of duplicate suppression. Example, SteveP born in London and another
topic map says SteveP born in Oslo, if required to only have one place of birth, a conflict that should be noticed.
</p>
<p><a name="d0e389"></a><b>Proposed Resolution</b> Defer
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e395"></a>2.6. psi-subclassing-loops
</h3>
<p><a name="d0e399"></a>Are subtype loops allowed? SteveN what are the inferences we hope to support? typeInstance, superType/subType, etc.
</p>
<p><a name="d0e402"></a><b>Proposed Resolution</b> Lars will research and report back.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e408"></a>2.7. locator-normalization
</h3>
<p><a name="d0e412"></a>If a locator syntax allows equivalent locators to be given different syntactical expressions normalization must be applied
in order to take this into account. Where should the text that sets out this requirement go? Does it belong in this document
or in the syntax specifications?
</p>
<p><a name="d0e415"></a>Lars, could write address of homepage, as http:www.ifinuiv.no/~larsga/ , /%Elargsa/, 80:%elarsga/ - a special case of string
normalization - should a processor always merge these three?
</p>
<p><a name="d0e418"></a>Michel Biezunski arrives
</p>
<p><a name="d0e421"></a>Martin Bryan arrives
</p>
<p><a name="d0e424"></a><b>Proposed Resolution</b> Normalization requirement is: String equivalency and nothing more. Put in a note to encourage better practice.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e430"></a>2.8. Agenda for tomorrow
</h3>
<p></p>
<ul>
<li><a name="d0e437"></a>plenary 1-2 hours
</li>
<li><a name="d0e440"></a><ul>
<li><a name="d0e443"></a>formal process for restatement
</li>
<li><a name="d0e446"></a>principles of restatement
</li>
</ul>
</li>
<li><a name="d0e450"></a>TMQL (2 hours)
</li>
<li><a name="d0e453"></a>TMCL
</li>
<li><a name="d0e456"></a>TNC + scope (rest of day
</li>
</ul>
<p></p>
<p><a name="d0e460"></a>Need a discussion of the principles.
</p>
</div>
</div>
<div class="teidiv">
<h2><a name="body.1_div.3"></a>3. 7 December 2002: SC34/WG3 Morning Session
</h2>
<p><b>Attendees</b></p>
<ul>
<li><a name="d0e475"></a>Steve Pepper
</li>
<li><a name="d0e478"></a>H. Holger Rath
</li>
<li><a name="d0e481"></a>Sung_Hyuk Kim
</li>
<li><a name="d0e484"></a>Soon_Bum Lim
</li>
<li><a name="d0e487"></a>Derek Millar
</li>
<li><a name="d0e490"></a>Mary Nishikawa
</li>
<li><a name="d0e493"></a>Patrick Durusau
</li>
<li><a name="d0e496"></a>Motomu Naito
</li>
<li><a name="d0e499"></a>Lars Marius Garshol
</li>
<li><a name="d0e502"></a>Jim Melton, Liason from SC32
</li>
<li><a name="d0e505"></a>Ann Wrightson
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e510"></a>3.1. TMQL Report (N0249)
</h3>
<p><a name="d0e515"></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="d0e518"></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="d0e521"></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="d0e524"></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="d0e529"></a>Jim Melton leaves.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e533"></a>3.2. Principles of Revision of ISO 13250
</h3>
<p><a name="d0e537"></a>Jim Mason arrives.
</p>
<p><a name="d0e540"></a>Steve Pepper: several options for revising ISO 13250. Ann Wrightson, are you saying update the roadmap? Michel, need to find
a framework for the roadmap. Pepper, 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.
Pepper, 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. Pepper: 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. Pepper: 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? Pepper:
but existing stuff needs to be changed.
</p>
<p><a name="d0e543"></a>Eric Freese arrives
</p>
<p><a name="d0e546"></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. Pepper:
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="d0e549"></a>Lars: there are some issues of XTM syntax as a result of the SAM.
</p>
<p><a name="d0e552"></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="d0e557"></a>Will not change XTM or HyTM in ways that will render existing topic maps syntactically invalid.
</p>
<p><a name="d0e560"></a>Newcomb: would be a way to kill HyTM if no one wants to work on it. Pepper, 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. Pepper: encourage
people to bring news of use of HyTM.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e564"></a>3.3. TMCL
</h3>
<p><a name="d0e568"></a>Pepper: status, approved as new work item 19756, draft requirements from July, 2001, have a couple of submissions, Ontopia
is one of them, Pepper 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. Pepper: 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="d0e571"></a><b>Summary</b> Editor will be instructed to solicit input and prepare a revision of the requirements document.
</p>
<p><a name="d0e576"></a>Nikita arrived after the morning break
</p>
</div>
</div>
<div class="teidiv">
<h2><a name="body.1_div.4"></a>4. 7 December 2002: SC34/WG3 Afternoon Session
</h2>
<p><b>Attendees</b></p>
<ul>
<li><a name="d0e591"></a>Steve Pepper
</li>
<li><a name="d0e594"></a>H. Holger Rath
</li>
<li><a name="d0e597"></a>Sung_Hyuk Kim
</li>
<li><a name="d0e600"></a>Soon_Bum Lim
</li>
<li><a name="d0e603"></a>Derek Millar
</li>
<li><a name="d0e606"></a>Mary Nishikawa
</li>
<li><a name="d0e609"></a>Patrick Durusau
</li>
<li><a name="d0e612"></a>Motomu Naito
</li>
<li><a name="d0e615"></a>Lars Marius Garshol
</li>
<li><a name="d0e618"></a>Ann Wrightson
</li>
<li><a name="d0e621"></a>Nikita Ogievetsky
</li>
<li><a name="d0e624"></a>Eric Freese
</li>
<li><a name="d0e627"></a>Jim Mason
</li>
</ul>
<p></p>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e631"></a>4.1. Topic Naming Constraint - Scope
</h3>
<p><a name="d0e636"></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. Pepper: 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. Pepper: 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. Pepper: 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="d0e639"></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="d0e647"></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, Pepper: need to offer guidance on usage
</p>
<p><a name="d0e650"></a><b>Proposed Resolution</b> see solution above.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e656"></a>4.2. names-with-types
</h3>
<p><a name="d0e661"></a>Done.
</p>
<p><a name="d0e664"></a><b>Proposed Resolution</b> Solution to TNC resolved this issue
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e670"></a>4.3. constr-single-subject-address
</h3>
<p><a name="d0e675"></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="d0e678"></a><b>Proposed Resolution</b> Defer
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e684"></a>4.4. prop-type-properties
</h3>
<p><a name="d0e689"></a>Should we name the type properties [association type], [role type], and [occurrence type], or should they all be called [type].
Pepper, owner of the type qualifies the type.
</p>
<p><a name="d0e692"></a><b>Proposed Resolution</b> Use type until a need shown for more specific terms.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e698"></a>4.5. psi-topicmaps.org
</h3>
<p><a name="d0e703"></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. Pepper: 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. Pepper: 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="d0e706"></a>Bernard arrives.
</p>
<p><a name="d0e709"></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>
<div class="teidiv">
<h2><a name="body.1_div.5"></a>5. 8 December 2002: SC34/WG3 Morning Session
</h2>
<p><b>Attendees</b></p>
<ul>
<li><a name="d0e726"></a>Derek Millar
</li>
<li><a name="d0e729"></a>Mary Nishikawa
</li>
<li><a name="d0e732"></a>Patrick Durusau
</li>
<li><a name="d0e735"></a>Motomu Naito
</li>
<li><a name="d0e738"></a>Lars Marius Garshol
</li>
<li><a name="d0e741"></a>Ann Wrightson
</li>
<li><a name="d0e744"></a>Eliot Kimber
</li>
<li><a name="d0e747"></a>Martin Bryan
</li>
<li><a name="d0e750"></a>Bernard Valant
</li>
<li><a name="d0e753"></a>Steve Newcomb
</li>
<li><a name="d0e756"></a>Holger Rath
</li>
<li><a name="d0e759"></a>Sung_Hyuk Kim
</li>
<li><a name="d0e762"></a>Soon_Bum Lim
</li>
<li><a name="d0e765"></a>Michel Biezunski
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e770"></a>5.1. term-scope-def
</h3>
<p><a name="d0e775"></a>The definition of scope is different from that of XTM 1.0 and ISO 13250:2000, in that it explicitly says topic characteristics
assignments are valid for each of the subjects in its scope individually. Is that acceptable?
</p>
<p><a name="d0e778"></a>Lars: All subjects view, only valid where all themes apply, vs. valid where any views apply, vs. say nothing, vs. structured
scope (Ann)
</p>
<p><a name="d0e781"></a>Newcomb: scope is just one of an unbounded number of assertions about assertions, see Steve's email, Scope, again. annoying
to have to define a class instance type to qualify a relationship. scope is an escape valve without defining an asertion type.
</p>
<p><a name="d0e784"></a>Ann: in XML can now only care about part of what is being said (without DTDs). but how to do strict policies where needed?
</p>
<p><a name="d0e787"></a>Newcomb: if scope gets very large and hard to manage, create specialized assertions that take the place of that scope. anything
that might want to say in a scope could have a special assertion type
</p>
<p><a name="d0e790"></a>Lars: does sort of beg the question about why have we encumbered the structure with scope? with the query language will need
to say that queries are executed within a particular scope.
</p>
<p><a name="d0e793"></a>Newcomb: would mean more complexity at query time, should use more specialized assertions if that is a problem.
</p>
<p><a name="d0e796"></a>Bernard: so namespace aspect is no longer a problem?
</p>
<p><a name="d0e799"></a>Newcomb: can make topics instanceOf a class that is to not display (or to display)
</p>
<p><a name="d0e802"></a>Ann: is this difference in topic maps as indexing level concept vs. topic maps as under the hood development tool?
</p>
<p><a name="d0e805"></a>Bernard: Newcomb wants to preserve the user's view.
</p>
<p><a name="d0e808"></a>Lars: declare topic that is not to be displayed and make everything an instanceOf itself.
</p>
<p><a name="d0e811"></a>Martin: Roles, where did they get off to?
</p>
<p><a name="d0e814"></a>Lars: must use published subject
</p>
<p><a name="d0e817"></a>Martin: can distinguish in ISO 13250 by role and scope.
<pre>
<Standard id="RDF">
<Name<Resource Data Framework</Name>
<Name lang="fr">....</Name>
<Used-In project="...">....</Used-In>
Name become a role, Used-In would be the scope
<occurs occrl="Used-In"
</pre>
</p>
<p><a name="d0e823"></a>Newcomb: would be pernicious to tighten up scope.
</p>
<p><a name="d0e826"></a>Lars: tightening here makes the query language easier
</p>
<p><a name="d0e829"></a>Newcomb: three choices, don't say, scopes mean extent of validity, or extent of validity with PSI.
</p>
<p><a name="d0e832"></a>Elliott: applicability
</p>
<p><a name="d0e835"></a>Generally should say extent of applicability and not extent of validity.
</p>
<p><a name="d0e838"></a>Lars: 1. Any Subjects, (XTM, 13250) 2. All Subjects (inconsistent with merging rules) , 3. Leave it open
#1 is dead, choice affects the interchange of topic maps. current merging rules imply "all subjects"
</p>
<p><a name="d0e841"></a>The union of scope is in ISO 13250 and Steve says it is an error.
</p>
<p><a name="d0e844"></a>Martin: certain that merging rules imply "all subjects"?
</p>
<p><a name="d0e847"></a>Newcomb: when merging topicmaps made by small "a" applications, may end up with a scope that cannot be interpreted. does not
want to lose integrity of scopes that have been expressed.
</p>
<p><a name="d0e850"></a>Ann: can't resolve this without resolving the facet war. Some of the examples should be done with facets.
</p>
<p><a name="d0e853"></a>Lars: still need to resolve legitimate use cases
</p>
<p><a name="d0e856"></a>Holger: three levels, lowest level is scope set itself, identity of scope level in RM (not true for SAM, only property of
characteristic), do we care about that in the SAM; next level, merging, scope governed merging, related to general question
of how to interpret scope, leave up to application, in context of SAM, this is a certain application of scope for merging;
can do ALL and use 3 for interpretation
</p>
<p><a name="d0e859"></a>Lars: 1. Merging, 2. Interpretation, 3. Interchange (2 is what does it mean? 3 is what happens when play by differnet rules
for scope) 4. TMCL/TMQL
</p>
<p><a name="d0e862"></a>Bernard: same problems occur in other places, problem occurs when have more than one subject composing the scope
</p>
<p><a name="d0e865"></a>Elliott: if a characteristic has two themes in its scope (Lars: scope does not affect merging of topics, only characteristics.)
</p>
<p><a name="d0e868"></a>Newcomb: do assertions wind up with multiple scopes?
</p>
<p><a name="d0e871"></a>Michel: give RM view of this issue? Easier to understand in these cases.
</p>
<p><a name="d0e874"></a>Newcomb: should we do this now?
</p>
<p><a name="d0e877"></a>Lars: some people have discussed it deeply but few people in this room have gotten the benefits of that discussion. Have a
document on this that people should read before the next meeting.
</p>
<p><a name="d0e880"></a>Ann: to what extent is it necessary to read all the mailing list to prepare for meetings, should try to improve processes.
</p>
<p><a name="d0e883"></a>Lars: could not finish SAM and did not get list of issues out for discussion.
</p>
<p><a name="d0e886"></a>Ann: need talk about 13250 but not limited to that single document. What can we say now about the nature of those consequences
now?
</p>
<p><a name="d0e889"></a>Newcomb: Lars' contributions have been heroic.
</p>
<p><a name="d0e892"></a><b>Proposed Resolution</b> defer to after lunch
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e898"></a>5.2. prop-scope-structure
</h3>
<p><a name="d0e902"></a>Should it be possible for the scopes of topic characteristic assignments to have internal structure?
</p>
<p><a name="d0e905"></a>Ann: does not want the standard to specify this structure, but a way to use scope with structure.
</p>
<p><a name="d0e908"></a>Elliott: experience with Cyc indicates that this should not be standardized. Have the ability so don't need to add anything.
</p>
<p><a name="d0e911"></a>Newcomb: would be delighted to say why it is pernicious to structure scope.
</p>
<p><a name="d0e914"></a><b>Proposed Resolution</b> Should the scope property continue to be a set of topic items? Answer is Yes for SAM.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e920"></a>5.3. err-constraint-violations
</h3>
<p><a name="d0e924"></a>Is it acceptable that constraint violations may be reported at any time?
</p>
<p><a name="d0e927"></a>Holger: errors appear in processing, should be mentioned when it happens, add a note has to report the error.
</p>
<p><a name="d0e930"></a>Lars: either constraint is violated or not, in a data model.
</p>
<p><a name="d0e933"></a>Michel: should use the reference model to track this sort of error, defer resolution on errors until we see the reference
model.
</p>
<p><a name="d0e936"></a>Newcomb: this is an editorial problem, say pre-condition and post-condition, say what would happen is you use a particular
algorithm and your results must match as though that algorithm was used.
</p>
<p><a name="d0e939"></a>Lars: will re-write to be in declarative style
</p>
<p><a name="d0e942"></a><b>Proposed Resolution</b> All errors must be reported in processing of a topic map and in a note that specifications building in this one will determine
when such errors are reported.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e948"></a>5.4. op-modifications
</h3>
<p><a name="d0e952"></a><b>Proposed Resolution</b> Should not define operations and the specification of merging should be re-written to a more declarative style. If declarative
formulation is found to be hard to understand, we may keep algorithm in an explanatory note.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e958"></a>5.5. reification-effects
</h3>
<p><a name="d0e962"></a>If you reify a topic name, does that affect your allowed type?
</p>
<p><a name="d0e965"></a>
<pre>
<topic ***>
<baseName> id-"a">
<instanceOf>#b</instanceOf>
<topic
subject1 (pointing to "a"
<instanceOf
</pre>
</p>
<p><a name="d0e971"></a>Ann: second one should be required to be name of type #b
</p>
<p><a name="d0e974"></a>Lars: could have two types (also an issue)
</p>
<p><a name="d0e977"></a>Ann: types should be fixed or calculated
</p>
<p><a name="d0e980"></a>Bernard: could use in thesarus construction
</p>
<p><a name="d0e983"></a>Lars: about the limit between the subject and topic world
</p>
<p><a name="d0e986"></a><b>Proposed Resolution</b> defer until after RM
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e992"></a>5.6. term-equal
</h3>
<p><a name="d0e996"></a>Should we speak about 'equality' of items or 'equivalence'? Are we comparing identity of items (equivalence) or equality of
their values?
</p>
<p><a name="d0e999"></a>Holger: means identity is the same. value equality in Java means equivalence: equality to be used for basic types, does evaluation
function matter. Lars: ready to go for equal.
</p>
<p><a name="d0e1002"></a><b>Proposed Resolution</b> Stick with equality.
</p>
</div>
</div>
<div class="teidiv">
<h2><a name="body.1_div.6"></a>6. 8 December 2002: SC34/WG3 Afternoon Session
</h2>
<p><b>Attendees</b></p>
<ul>
<li><a name="d0e1019"></a>Derek Millar
</li>
<li><a name="d0e1022"></a>Mary Nishikawa
</li>
<li><a name="d0e1025"></a>Patrick Durusau
</li>
<li><a name="d0e1028"></a>Motomu Naito
</li>
<li><a name="d0e1031"></a>Lars Marius Garshol
</li>
<li><a name="d0e1034"></a>Ann Wrightson
</li>
<li><a name="d0e1037"></a>Eliot Kimber
</li>
<li><a name="d0e1040"></a>Martin Bryan
</li>
<li><a name="d0e1043"></a>Bernard Valant
</li>
<li><a name="d0e1046"></a>Steve Newcomb
</li>
<li><a name="d0e1049"></a>Holger Rath
</li>
<li><a name="d0e1052"></a>Sung_Hyuk Kim
</li>
<li><a name="d0e1055"></a>Soon_Bum Lim
</li>
<li><a name="d0e1058"></a>Michel Biezunski
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1063"></a>6.1. Short Tour of Reference Model
</h3>
<p><a name="d0e1068"></a>Newcomb: subjects are primarily conferred upon nodes, node has a subject by virtue of playing a role in one or more assertions,
a node's situation in the graph, is what gives the node its subject. assertions yield subjects to the nodes that are role
players. how is the subject represented? nodes have properties, which are values? requires to say a type but does not have
a type system. properties get values from their situationess, assertion type, roles played and applications' definion of what
properties should be assigned to those nodes. Two kinds of properties, SIDP, subject identity discrimination properties. Ann:
linguistic structure is primary and formal structure is secondary. What is merging? 1. have a topic map graph, some nodes
inside assertions, others are not: merging process, looks at every node to determine it situation in the graph, graph must
be well-formed, well-formed may have multiple nodes for the same subject, then calculate all the property values for all the
nodes, all of the assertion types have been defined, 2. then look at values, SIDP, when nodes have the same values, if merger
has occurred, then have to go back and start over again (since the situations have changed) Logic of the application drives
the merging process. Whenever a user defines an assertion type, have defined a subtype of the SAM. Users may want to define
merging rules for cases when certain types of assertions are used.
</p>
<p><a name="d0e1071"></a>Newcomb: diagram, the node of interest on left, need to know the notation of the subject indicator, Theory of Resource Identity,
Theory of Subject Indication, Addressing Scheme. What is the subject of the subject indicator node, gets its subject from
its situation, because of its role, address <nmsploc...> Ann: but HyTime would not work with some systems, Elliott: HyTime
addresses a unique physical thing in the entire universe, It has an address as well, (URI not sufficient for a binding point).
URI's are not binding points unless the strings match. Punch line: SAM can bootstrap URI into stronger addressing such as
the moral equivalent of a grove. Without enhancing the web somehow, can't do serious information management. Semantic web
is doing work related to subjects.
</p>
<p><a name="d0e1074"></a>Ann: RDF is dealing with names.
</p>
<p><a name="d0e1077"></a>Subject-Locator
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1081"></a>6.2. term-subject-address-def
</h3>
<p><a name="d0e1085"></a>At what level of interpretation does the topic represent the resource? Does it represent that storage location? The stream
of bytes? The stream of bytes interpreted in some particular way? The standard must either leave the details open or clarify
this. Note that it may be impossible to clarity whnt the interpretation is left undefined.
</p>
<p><a name="d0e1088"></a>Elliotte: nothing in the use of resourceRef that licenses you to interpret anything about the subject
</p>
<p><a name="d0e1091"></a>Bernard: could use a public subject identifier
</p>
<p><a name="d0e1094"></a>Lars: meaning in ultimately something you cannot reach
</p>
<p><a name="d0e1097"></a>Lars: resourceRef in and of itself does not tell you what it meant. It is the resource and not the URI.
</p>
<p><a name="d0e1100"></a><b>Proposed Resolution</b> The precise definition of the subject address reference is unknown. The subject has something to do with the resource but
we don't know what.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1106"></a>6.3. locator-reference
</h3>
<p><a name="d0e1111"></a>Must locators really refer to information resources? Some URN schemes allow resources tht are not information resources to
be addressed. This affects the definitions of "information resource", "locator", as well as the [subject identifiers] and
[subject address] properties.
</p>
<p><a name="d0e1114"></a>Newcomb: Use Fielding approach to subject identity.
</p>
<p><a name="d0e1117"></a>Elliotte: create a reliable binding point in the topic map, the whole point of subject identity. was to point to another topic
in the topic map.
</p>
<p><a name="d0e1120"></a>Lars: Fielding has a URN scheme, tbd:http://................, semantics are identical to normal subjectIndicator
</p>
<p><a name="d0e1123"></a>Elliotte: subject indicator vs. subject address, in XTM syntax can be distinguished.
</p>
<p><a name="d0e1126"></a>Lars: can have a topic that does not represent an information resource, use URI that is not resolveable in a resourceRef,
if no byte stream, a reportable error.
</p>
<p><a name="d0e1129"></a>Bernard: can't impose strict error condition b/c server may just not reply
</p>
<p><a name="d0e1132"></a>Sam: some people may want this level validation
</p>
<p><a name="d0e1135"></a>Newcomb: agrees with Lars, have to say in the spec, what you mean when you utter a resourceRef,
</p>
<p><a name="d0e1138"></a><b>Proposed Resolution</b> Use Fielding position, ineffable identity referenced by the locator.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1144"></a>6.4. infinite-subject-spaces
</h3>
<p><a name="d0e1148"></a>How should values from infinite subject spaces be represented in topic maps?
</p>
<p><a name="d0e1151"></a>Lars: logic usually used with set theory, graph theory builds upon it. set theory, member-of, subset-of, implies that sets
are discrete objects, set theory forces you to be discrete, should be continuous subject spaces rather than infinite subject
spaces. Marriology (sp?)
</p>
<p><a name="d0e1154"></a>Newcomb: RM can deal with this, topic map is subset of all topics,
</p>
<p><a name="d0e1157"></a>Ann: need a holder for ways for others to work this out for particular domains
</p>
<p><a name="d0e1160"></a>Lars: create a topic for a train, and creates a topic for a railway, then wants to say with association, this train was used
on this railway, from 1937 to 1972. How to say this?
</p>
<p><a name="d0e1163"></a>Newcomb: here have a section of a timeline, a finite coordinate space.
</p>
<p><a name="d0e1166"></a>Elliotte: only has to put in the start and end of the range and not everything in between
</p>
<p><a name="d0e1169"></a>Bernard: linked to something lacking from the beginning, people don't want to create topics for every date and don't want
dates to be occurrences. does not fit with normal idea of occurrences.
</p>
<p><a name="d0e1172"></a>Martin: date is not an occurrence of a topic, put an axis in to point to, property value pairs associate with topics.
</p>
<p><a name="d0e1175"></a>Newcomb: can make an assertion about a topic that has a range in which a topic is valid.
</p>
<p><a name="d0e1178"></a>Newcomb: occurrences are really the requirement that a relationship exists between a subject and a piece of information
</p>
<p><a name="d0e1181"></a>Ann: cannot go there, user requirement that need imprecise dates, Ex. Oct. rather than a particular date, is it before or
after Oct. 15th? is I don't know.
</p>
<p><a name="d0e1184"></a>Newcomb: SAM is the substructure on which other ^A_A/A/applications will be built.
</p>
<p><a name="d0e1187"></a><b>Proposed Resolution</b> Should leave it alone.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1193"></a>6.5. strings-as-subjects
</h3>
<p><a name="d0e1198"></a>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?
</p>
<p><a name="d0e1201"></a>Newcomb: 2.1 requires that a string be read as a particular string
</p>
<p><a name="d0e1204"></a>Lars: user's don't want to create a topic for 24 degrees Celius, just to list the temperature. don't know what it is the name
of. If use a name type
</p>
<p><a name="d0e1207"></a>Newcomb: strings can in particular locations, or strings that have no context,
</p>
<p><a name="d0e1210"></a>Bryan: how to decide what meaning "run" has in a particular case
</p>
<p><a name="d0e1213"></a>Lars: [tzy="24C"] [lmg="Lars M"] these are identical in terms of syntax
</p>
<p><a name="d0e1216"></a>Newcomb: when you have resourceData, does it have context or not?
</p>
<p><a name="d0e1219"></a>Ann: two concepts of string, actually mean the equivalence class of strings, name is one of the possible uses,
</p>
<p><a name="d0e1222"></a>Newcomb: node demanders, define a syntax for interchange and deserialization procedure, can define things in the syntax that
you want to point at in deserialization, can point at the node or information item that results from deserialization. can
do the same as the baseNameString.
</p>
<p><a name="d0e1225"></a><b>Proposed Resolution</b> Defer
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1231"></a>6.6. Future plans for SAM
</h3>
<p><a name="d0e1236"></a>Editor will produce a new draft with all these issues included, probably after Christmas. For comment by national bodies,
Should have ready by London in May. London should be TMCL and TMQL. will also produce a list of proposed solutions
</p>
</div>
</div>
<div class="teidiv">
<h2><a name="body.1_div.7"></a>7. 9 December 2002: SC34/WG3 Morning Session
</h2>
<p><b>Attendees</b></p>
<ul>
<li><a name="d0e1251"></a>Derek Millar
</li>
<li><a name="d0e1254"></a>Patrick Durusau
</li>
<li><a name="d0e1257"></a>Motomu Naito
</li>
<li><a name="d0e1260"></a>Ann Wrightson
</li>
<li><a name="d0e1263"></a>Steve Newcomb
</li>
<li><a name="d0e1266"></a>Sam Hunting
</li>
<li><a name="d0e1269"></a>Sung-Hyuk Kim
</li>
<li><a name="d0e1272"></a>Steve Pepper
</li>
<li><a name="d0e1275"></a>Michel Biezunski
</li>
<li><a name="d0e1278"></a>Bernard Valant
</li>
<li><a name="d0e1281"></a>Eric Freese
</li>
<li><a name="d0e1284"></a>Eliot Kimber
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1289"></a>7.1. ISO-HTML
</h3>
<p><a name="d0e1294"></a>status: published
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1298"></a>7.2. ISMID
</h3>
<p><a name="d0e1302"></a>N337 Defect Report: Cooper, will function as defect editor, has submitted changes.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1306"></a>7.3. HyTime
</h3>
<p><a name="d0e1311"></a>Architectual forms in XML, amendment and TC in the works, N1985, N1988, which consitute revisions to the standard. are they
complete? Kimber: N1957 - Architectual forms by processing instructions only, the TC is completely different, that document
is not complete, would require completely executive decisions or gets time from Pete to work on it. Kimber has only real HyTime
implementation but no customers using it. amendment is not all that pressing, Kimber: treat HyTime as archival and move on.
withdraw TC. Ann: considers TC would be beneficial to the standard. (N1988) Newcomb: thinks HyTime should explode into a family
of standards.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1315"></a>7.4. SMDL
</h3>
<p><a name="d0e1319"></a>Balloted and approved so could just publish it. Does not conform to current HyTime draft. Newcomb: has been delayed for seven
years so what is another year? Kimber: SteveP says SMDL was out of variance with HyTime, can't really fix the syntax without
a data model, worked with SteveN, would be quite solid, Kimber has a draft ready for SteveN to read. Newcomb: more a chance
for mischief if publish it with problems. Ann: should not pursue non-commercially viable work in the ISO process, the priority
should be given to topic map stadards, defer this work until after the topic maps standards are complete. Kimber: can file
an interim draft
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1323"></a>7.5. Topic Map Reference Model
</h3>
<p><a name="d0e1327"></a>Newcomb: RM is an attempt to allow 100 flowers to bloom. the collocation objective (Elaine's book), all information about
a subject is known from a particular point. The SAM is once instance of the RM but there could be others. Pepper: what is
meant by ontology? Newcomb: can express John Sowa's ontology in the RM by specifying a TM App (the SAM should be one)
</p>
<p><a name="d0e1330"></a>Pepper: no doubt that he is impressed by the RM (and PMTM4) leading us forward from ISO 13250, but for that reason, worried
that we are in danger of letting topic maps continuing to evolve, do have to move onto the next stage. thinks we need to draw
the line, but RM is taking us beyond topic maps. had a point when 13250 appeared that was well defined. proposes whether we
should make the RM a new work item, with its own number, etc., Steve and Michel resign as 13250 editors and let Lars continue
in that role.
</p>
<p><a name="d0e1333"></a>Nikita arrives
</p>
<p><a name="d0e1336"></a>Sam: objects to severing the connection. Michel: important to know what we are going to do. Agrees with analysis about what
is happening with topic maps, but disagrees with conclusion. wants a stable standard, also thinks that standard cannot be
completely fixed. don't need to simply protected vested interests in the current standard. not really interested in the position
of editor, topic map standard should be one standard. SAM is a formalization of XTM, and RM is the mechanism that allows enabling
something else.
</p>
<p><a name="d0e1339"></a>Sam: not sure about the analogy between SGML/HyTime is the best one, SGML/XML is the better one, ISO lost control of SGML,
issue is not one of freezing it, in the form of the SAM, preserving brand under ISO
</p>
<p><a name="d0e1342"></a>Newcomb: issue is not what any of us are talking about, feels like the SAM needs the RM, to preserve the SAM. wrong headed
from long term perspective, to create SAM with merging rules on assertion types that are built into the SAM, to restrict the
SAM to merging rules limits the use of topic maps. SAM is something to inherit, may want to create assetion types
</p>
<p><a name="d0e1345"></a>Ann: have an established position that is known as topic maps, need to distinguish the broader thing from the narrower.
</p>
<p><a name="d0e1348"></a>Newcomb: promote the SAM but have the RM for additional power. do we want to limit the brand name topic maps to a particular
ontology. Pepper: agrees, do users need to understand the RM to use topic maps, great danger that we will kill the topic map
paradigm. Michel: believes that RM does not have anything to do with knowledge representation as we speak of it in topic maps.
topic map user, topic map implementer (must use the SAM) Newcomb: must get our story straight
</p>
<p><a name="d0e1351"></a>Bernard: RM does not have to be an explicit part of the standard. Ann: if the RM is necessary machinery for the SAM, then
place for it is in an annex. Sam: sympathetic to branding, are we going to restrict topic maps to the SAM assocition types.
Pepper: goes beyond topic maps and should be a standard in its own right. could be used with RDF-2, possibly. need more time
to develop RM, not in line with schedule for the SAM. Michel: completely disagrees with what Pepper said, pretending RM is
above topic maps, standards work is 10% technical and 90% political, RM is a way to show interoperability
</p>
<p><a name="d0e1354"></a>Pepper: going back to the agenda, no formal proposal on RM at this time.
</p>
<p><a name="d0e1357"></a>Newcomb: can talk about defining an Application "big A" or SAM issues.
</p>
<p>Draft reference model say 10 things an Application must do:</p>
<ul>
<li><a name="d0e1364"></a>1. A name that is different from the name of any other conforming TM Application
</li>
<li><a name="d0e1367"></a>2. A set of definitions of the properties of nodes and their value types, specifying which property values are intended to
be used for purposes of deciding whether nodes have identical subjects (i.e., specifying which are SIDPs, and which are OPs).
(See 5.2.2.)
</li>
<li><a name="d0e1370"></a>3. The validity constraints on the values of the properties of nodes. (See 5.2.3.) (Newcomb: validity means that if the constraints
are not meet, will throw an error. Elliot: would remove validity if there are no other constraints. Newcomb: a recipe for
writing a standard, Elliot agrees.)
</li>
<li><a name="d0e1373"></a>4. A set of situation features other than service as the x endpoints of Cx arcs, and the property values that must be conferred
on the nodes so situated. (The purpose of these property values is to enable arc traversals within assertions. Not all intra-assertion
arc traversals are required to be enabled. See 5.2.4.) (Newcomb: node is situated by being at the end point of any number
of arcs. your service as end points of arcs, that constitutes the situation. situations have situation features, as serving
as the end point of particular arcs. two kinds of situation features, role player is a kind of situation feature, some nodes
are inside associations and those situation features are described by the RM, significance of the nodes internal to associations
is reserved to the RM, assertion internal things. Requires Applications to provide properties for nodes that are inside assertions.
All Applications have to honor the RM notion of what an assertions is.)
</li>
<li><a name="d0e1376"></a>5. A set of assertion types, the role types of each assertion type, the validation constraints on their instances, and the
property values that must be conferred upon the role players of their instances. (See 5.2.5.) (Newcomb: heart of the matter.
this is what is happening in the SAM now. Ann: can we find another word for conferred. assertion types should be fully explained.
Newcomb: yes. anytime you define an assertion type. for baseName, example on board Pepper: property is defined by the Application
Newcomb: no common properties defined by the RM)
</li>
<li><a name="d0e1379"></a>6. Rules for determining whether the values of any given node's subject identity discrimination properties (SIDPs) are consistent
with each other. (See 5.2.6.) (Newcomb: these are defined by the Application. baseName, baseNameString, in the current SAM,
Bernard: primitive values? Newcomb: ok but not in the sense of datatype
</li>
<li><a name="d0e1382"></a>7. A set of built-in nodes, with built-in property values, that must appear in every topic map graph that conforms to the
TM Application. (See 5.2.7.)
</li>
<li><a name="d0e1385"></a>8. The rules for merging nodes on the basis of their subject identity discrimination properties (SIDPs). (See 5.2.8.)
</li>
<li><a name="d0e1388"></a>9. The rules for combining the built-in values of the properties of built-in nodes during merging, if the designers of the
TM Application anticipate the need for such combination. (See 5.2.9.)
</li>
<li><a name="d0e1391"></a>10. If the TM Application defines one or more interchange syntaxes, the procedures for constructing topic map graphs from
instances of each syntax ("Syntax Processing Models"), and "node demander" rules that allow topic map graph nodes to be indirectly
addressed by addressing their corresponding syntactic constructs. (See 5.2.10.) (Newcomb: must be specified in RM terminology.
Pepper: d
</li>
</ul>
<p>
</p>
<p><a name="d0e1396"></a>Newcomb: can't have multiple role players of the same role, such as two topics with the role type, Bernard, does not get the
explanation, gets rid of all the issues of cardinality. if don't have a node that does not reify the set, you don't have a
topic that reifies the node. discussion ensues about implicit sets, etc.
</p>
<p><a name="d0e1399"></a></p>
</div>
</div>
<div class="teidiv">
<h2><a name="body.1_div.8"></a>8. 9 December 2002: SC34/WG3 Afternoon Session
</h2>
<p><b>Attendees</b></p>
<ul>
<li><a name="d0e1413"></a>Derek Millar
</li>
<li><a name="d0e1416"></a>Patrick Durusau
</li>
<li><a name="d0e1419"></a>Motomu Naito
</li>
<li><a name="d0e1422"></a>Ann Wrightson
</li>
<li><a name="d0e1425"></a>Steve Newcomb
</li>
<li><a name="d0e1428"></a>Sam Hunting
</li>
<li><a name="d0e1431"></a>Sung-Hyuk Kim
</li>
<li><a name="d0e1434"></a>Steve Pepper
</li>
<li><a name="d0e1437"></a>Michel Biezunski
</li>
<li><a name="d0e1440"></a>Bernard Valant
</li>
<li><a name="d0e1443"></a>Jean Delahousse
</li>
<li><a name="d0e1446"></a>Eric Freese
</li>
<li><a name="d0e1449"></a>Elliote Kimber
</li>
<li><a name="d0e1452"></a>Nikita Ogievetsky
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1457"></a>8.1. Bernard Valant with Graph Theory
</h3>
<p><a name="d0e1462"></a>subjects and hypergraph is defined as distinct sets, HyperGraphTM, hypergraph is a set, dealing with sets, three distinct
sets of hypergraph elements. 1. An element is either vertex, edge, incidence. must choose to be in one and not the others.
2. Every incidence links exactly one vertex and one edge. (this is the unique rule for hypergraphs) edge in a regular graph
can only connect two nodes with one edge, hypergraph connects two nodes and an incidence, which are three nodes on one edge.
</p>
<p><a name="d0e1465"></a>current model (as shown) does not represent the entire range of constructs from the RM. Ann: will give us traversal properties
for the RM, if completely mapped.
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1469"></a>8.2. Newcomb on Roles
</h3>
<p><a name="d0e1474"></a>Nikita wants to say that a, b, and c are true friends, wants to use one role type that three people are friends. wants to
say this with one role type, three different roles of the same type, could add a set assertion type in SAM to confer membership
property which is also SDIP.
</p>
<p><a name="d0e1477"></a>Example from Martin Bryan on the SC34 list, brother Martin and his brother Ian, two roles and one role type. this is in association
land. Let's say brothers are always binary. this association type gets turned into an assertion.
<pre>
Ian-left-brother-----AssertionType-----right-brother-Martin
Martin-left-brother-----AssertionType-----right-brother-Ian
Impact of existence is exactly the same. situation of the two nodes are symetical.
</pre>
</p>
</div>
<div class="teidiv">
<h3><a name="SC34_6-9Dec2002-div-d0e1484"></a>8.3. Newcomb on SAM issues
</h3>
<p><a name="d0e1488"></a>Newcomb: the RM assumes the applications have direct access to the graph, nodes and properties. SAM as written has different
view, has a notion of reification, have to reify something in order for it to be an information item. behave as if they did
exist, whether created as objects or just pretend they exist. Makes the SAM quite different from the RM. Should RM have an
API as an optional feature, can also define optional API characteristics? Pat: can't SAM do less than the RM? Newcomb: yes.
RM should say that the SAM can do it.
</p>
<p><a name="d0e1491"></a>Pepper: anything else that affects the SAM? Newcomb: don't think so, #2 in the RM needs to be looked at in the SAM, RM says
you must say what are the subjects. Pepper: should map RM to the SAM, agreed in the roadmap, Newcomb: agrees it should be
done
</p>
<p><a name="d0e1494"></a>Pepper: can strings be subjects? Newcomb: could make this decision, but do need to decide.
</p>
<p><a name="d0e1497"></a>Pepper: scopes are not first class objects. From the HyTM example, #2 and #3, baseName reification is #3, not #2.
</p>
<p><a name="d0e1500"></a>Pepper: decisions on RM, Newcomb, probably premature. Newcomb willing to spear head work on mapping RM to the SAM. Should
use the brothers example on roles. r-node as an issue, requirement #10, next meeting 7:30 PM Thursday night
</p>
</div>
</div>
<hr>
<div class="footer">Comments/Corrections should be directed to the topic map list, <a href="mailto:sc34wg3@isotopicmaps.org">sc34wg3@isotopicmaps.org</a>.</div>
</body>
</html>
--------------050505010100050908000201--