[sc34wg3] Friday Draft Minutes: SC34/WG3
Patrick Durusau
sc34wg3@isotopicmaps.org
Fri, 06 Dec 2002 19:44:25 -0500
This is a multi-part message in MIME format.
--------------030407030803030208050801
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.
As you can see, a lot of progress was made on the SAM today!
Please post comments to the list.
Patrick
--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
--------------030407030803030208050801
Content-Type: text/html; charset=us-ascii;
name="sc34_6Nov2002.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="sc34_6Nov2002.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 November 2002</title>
<link rel="stylesheet" type="text/css" href="/stylesheets/tei-oucs.css">
<meta name="DC.Title" content="SC34 Meeting, Baltimore, 6 November 2002">
<meta name="DC.Author" content="">
<meta name="DC.Language" content="(SCHEME=iso639) en">
<meta name="DC.Creator" content="Oxford University Computing Services, 13 Banbury Road, Oxford OX2 6NN, United Kingdom">
<meta name="DC.Creator.Address" content="webmaster@oucs.ox.ac.uk">
</head>
<body><a name="TOP"></a><table class="header" width="100%">
<tr>
<td align="left">
<h1 class="maintitle">Unofficial Minutes, SC34/WG3 Meeting, Baltimore, 6 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">Morning Session</a><ul class="toc">
<li class="toc">1.1. <a class="toc" href="#sc34_6Nov2002-div-d0e80">Subject and Resource</a></li>
<li class="toc">1.2. <a class="toc" href="#sc34_6Nov2002-div-d0e99">Dependencies on RDF</a></li>
<li class="toc">1.3. <a class="toc" href="#sc34_6Nov2002-div-d0e109">Reifiers and Merging</a></li>
<li class="toc">1.4. <a class="toc" href="#sc34_6Nov2002-div-d0e125">merge-srcloc-vs-subject 4.1 Merging Topics</a></li>
<li class="toc">1.5. <a class="toc" href="#sc34_6Nov2002-div-d0e141">term-subject-def</a></li>
<li class="toc">1.6. <a class="toc" href="#sc34_6Nov2002-div-d0e154">prop-notation-interp</a></li>
<li class="toc">1.7. <a class="toc" href="#sc34_6Nov2002-div-d0e167">prop-reifier-topic</a></li>
<li class="toc">1.8. <a class="toc" href="#sc34_6Nov2002-div-d0e180">string-normalization</a></li>
<li class="toc">1.9. <a class="toc" href="#sc34_6Nov2002-div-d0e198">string-bidi</a></li>
<li class="toc">1.10. <a class="toc" href="#sc34_6Nov2002-div-d0e211">container-props</a></li>
<li class="toc">1.11. <a class="toc" href="#sc34_6Nov2002-div-d0e224">term-topic-characteristic-reified</a></li>
<li class="toc">1.12. <a class="toc" href="#sc34_6Nov2002-div-d0e237">subject-identity-established</a></li>
<li class="toc">1.13. <a class="toc" href="#sc34_6Nov2002-div-d0e250">prop-reifier-computed</a></li>
<li class="toc">1.14. <a class="toc" href="#sc34_6Nov2002-div-d0e263">prop-base-locator</a></li>
</ul>
</li>
<li class="toc">2. <a class="toc" href="#body.1_div.2">Afternoon Session</a><ul class="toc">
<li class="toc">2.1. <a class="toc" href="#sc34_6Nov2002-div-d0e324">term-application</a></li>
<li class="toc">2.2. <a class="toc" href="#sc34_6Nov2002-div-d0e337">prop-srcloc-interchange</a></li>
<li class="toc">2.3. <a class="toc" href="#sc34_6Nov2002-div-d0e356">op-sorting</a></li>
<li class="toc">2.4. <a class="toc" href="#sc34_6Nov2002-div-d0e369">psi-display-name</a></li>
<li class="toc">2.5. <a class="toc" href="#sc34_6Nov2002-div-d0e382">merge-use-of-schemas</a></li>
<li class="toc">2.6. <a class="toc" href="#sc34_6Nov2002-div-d0e395">psi-subclassing-loops</a></li>
<li class="toc">2.7. <a class="toc" href="#sc34_6Nov2002-div-d0e408">locator-normalization</a></li>
<li class="toc">2.8. <a class="toc" href="#sc34_6Nov2002-div-d0e430">Agenda for tomorrow</a></li>
</ul>
</li>
</ul>
<div class="teidiv">
<h2><a name="body.1_div.1"></a>1. 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 Miller
</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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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. 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 Miller
</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
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="sc34_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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_6Nov2002-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 joins the discussion
</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_6Nov2002-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>
<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>
--------------030407030803030208050801--