[sc34wg3] SC34/WG3 Draft Minutes - 9 December 2002
Patrick Durusau
sc34wg3@isotopicmaps.org
Mon, 09 Dec 2002 18:51:05 -0500
This is a multi-part message in MIME format.
--------------060204070809060704080809
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Greetings,
Those of you unable to attend missed a very productive and interesting
set of meetings by WG3! There were few decisions made today but there
was a great deal of technical discussion, only part of which I was able
to capture in my notes.
Note that there is a recognized need to map between the reference model
and the SAM. Steve Newcomb will be leading that work and will readily
welcome assistance in that task. Even assisting in that task will give
you a deeper view of topic map machinery than most other implementors so
look at it as learning to build a better implementation than your
competitors. ;-)
Patrick
--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
--------------060204070809060704080809
Content-Type: text/html; charset=us-ascii;
name="sc34_9Dec2002.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="sc34_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>Draft Minutes: SC34/WG3 Meeting, Baltimore, 9 December 2002</title>
<link rel="stylesheet" type="text/css" href="/stylesheets/tei-oucs.css">
<meta name="DC.Title" content="Draft Minutes: SC34/WG3 Meeting, Baltimore, 9 December 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, 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">SC34/WG3 Morning Session</a><ul class="toc">
<li class="toc">1.1. <a class="toc" href="#sc34_9Dec2002-div-d0e80">ISO-HTML</a></li>
<li class="toc">1.2. <a class="toc" href="#sc34_9Dec2002-div-d0e89">ISMID</a></li>
<li class="toc">1.3. <a class="toc" href="#sc34_9Dec2002-div-d0e97">HyTime</a></li>
<li class="toc">1.4. <a class="toc" href="#sc34_9Dec2002-div-d0e106">SMDL</a></li>
<li class="toc">1.5. <a class="toc" href="#sc34_9Dec2002-div-d0e114">Topic Map Reference Model</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_9Dec2002-div-d0e248">Bernard Valant with Graph Theory</a></li>
<li class="toc">2.2. <a class="toc" href="#sc34_9Dec2002-div-d0e260">Newcomb on Roles</a></li>
<li class="toc">2.3. <a class="toc" href="#sc34_9Dec2002-div-d0e275">Newcomb on SAM issues</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>Derek Millar
</li>
<li><a name="d0e45"></a>Patrick Durusau
</li>
<li><a name="d0e48"></a>Motomu Naito
</li>
<li><a name="d0e51"></a>Ann Wrightson
</li>
<li><a name="d0e54"></a>Steve Newcomb
</li>
<li><a name="d0e57"></a>Sam Hunting
</li>
<li><a name="d0e60"></a>Sung-Hyuk Kim
</li>
<li><a name="d0e63"></a>Steve Peppers
</li>
<li><a name="d0e66"></a>Michel
</li>
<li><a name="d0e69"></a>Bernard
</li>
<li><a name="d0e72"></a>Eric Freese
</li>
<li><a name="d0e75"></a>Elliote Kimber
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="sc34_9Dec2002-div-d0e80"></a>1.1. ISO-HTML
</h3>
<p><a name="d0e85"></a>status: published
</p>
</div>
<div class="teidiv">
<h3><a name="sc34_9Dec2002-div-d0e89"></a>1.2. ISMID
</h3>
<p><a name="d0e93"></a>N337 Defect Report: Cooper, will function as defect editor, has submitted changes.
</p>
</div>
<div class="teidiv">
<h3><a name="sc34_9Dec2002-div-d0e97"></a>1.3. HyTime
</h3>
<p><a name="d0e102"></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_9Dec2002-div-d0e106"></a>1.4. SMDL
</h3>
<p><a name="d0e110"></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_9Dec2002-div-d0e114"></a>1.5. Topic Map Reference Model
</h3>
<p><a name="d0e118"></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. Peppers: 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="d0e121"></a>Peppers: 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="d0e124"></a>Nikita arrives
</p>
<p><a name="d0e127"></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="d0e130"></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="d0e133"></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="d0e136"></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="d0e139"></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. Peppers: 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="d0e142"></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.
Peppers: 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 Peppers 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="d0e145"></a>Peppers: going back to the agenda, no formal proposal on RM at this time.
</p>
<p><a name="d0e148"></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="d0e155"></a>1. A name that is different from the name of any other conforming TM Application
</li>
<li><a name="d0e158"></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="d0e161"></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="d0e164"></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="d0e167"></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 Peppers: property is defined by the Application
Newcomb: no common properties defined by the RM)
</li>
<li><a name="d0e170"></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="d0e173"></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="d0e176"></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="d0e179"></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="d0e182"></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.
Peppers: d
</li>
</ul>
<p>
</p>
<p><a name="d0e187"></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="d0e190"></a></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="d0e204"></a>Derek Millar
</li>
<li><a name="d0e207"></a>Patrick Durusau
</li>
<li><a name="d0e210"></a>Motomu Naito
</li>
<li><a name="d0e213"></a>Ann Wrightson
</li>
<li><a name="d0e216"></a>Steve Newcomb
</li>
<li><a name="d0e219"></a>Sam Hunting
</li>
<li><a name="d0e222"></a>Sung-Hyuk Kim
</li>
<li><a name="d0e225"></a>Steve Peppers
</li>
<li><a name="d0e228"></a>Michel
</li>
<li><a name="d0e231"></a>Bernard
</li>
<li><a name="d0e234"></a>Jean
</li>
<li><a name="d0e237"></a>Eric Freese
</li>
<li><a name="d0e240"></a>Elliote Kimber
</li>
<li><a name="d0e243"></a>Nikita
</li>
</ul>
<p>
</p>
<div class="teidiv">
<h3><a name="sc34_9Dec2002-div-d0e248"></a>2.1. Bernard Valant with Graph Theory
</h3>
<p><a name="d0e253"></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="d0e256"></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_9Dec2002-div-d0e260"></a>2.2. Newcomb on Roles
</h3>
<p><a name="d0e265"></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="d0e268"></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_9Dec2002-div-d0e275"></a>2.3. Newcomb on SAM issues
</h3>
<p><a name="d0e279"></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="d0e282"></a>Peppers: 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. Peppers: should map RM to the SAM, agreed in the roadmap, Newcomb: agrees it should be
done
</p>
<p><a name="d0e285"></a>Peppers: can strings be subjects? Newcomb: could make this decision, but do need to decide.
</p>
<p><a name="d0e288"></a>Peppers: scopes are not first class objects. From the HyTM example, #2 and #3, baseName reification is #3, not #2.
</p>
<p><a name="d0e291"></a>Peppers: 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 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>
--------------060204070809060704080809--