<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<tt>
<b>Chat transcript from room: ontoiop_20150126</b><br>
<b>2015-01-26 GMT-08:00</b><br>
<b>[07:59] </b>anonymous morphed into Ed Seidewitz<br>
<b>[08:01] </b><b>TillMossakowski1: </b>Ed, Jim, are you on the
call?<br>
<b>[08:02] </b>anonymous morphed into MihaiCodescu<br>
<b>[08:02] </b>anonymous1 morphed into Alexander Knapp<br>
<b>[08:02] </b><b>TerryLongstreth: </b>there's a term with which
I'm unfamiliar: "abuse of notation"<br>
<b>[08:03] </b><b>TillMossakowski1: </b>Till presents the slides
(sent to mailing list)<br>
<b>[08:07] </b><b>TillMossakowski1: </b><a class="moz-txt-link-freetext" href="http://iws.cs.uni-magdeburg.de/~mossakow/Slides-OntoIOp.pdf">http://iws.cs.uni-magdeburg.de/~mossakow/Slides-OntoIOp.pdf</a><br>
<b>[08:14] </b><b>TillMossakowski1: </b>properties only cover
query operations, full operations would lead to state changes<br>
<b>[08:16] </b><b>TillMossakowski1: </b>Ed: instances of classes
are addressed by reference and can be aliased. This leads to
problems in the logical representation if the state can change.
You need a notion of independent existence of objects.<br>
<b>[08:16] </b><b>TillMossakowski1: </b>Fabian: we are following
Conrad's proposal to keep things static<br>
<b>[08:23] </b><b>FabianNeuhaus: </b>correction on Models via
translation slide: replace "class" by "class or datatype"<br>
<b>[08:26] </b><b>TillMossakowski1: </b>Ed: you do not have
lists or sets in UML, but the only emerge through ordering
properties on associations<br>
<b>[08:31] </b><b>TillMossakowski1: </b>Alexander: we could
separate the basic information of the class diagrams from the
information whether the types of properties and return parameters
of operations are orderd or not, unique or not etc.<br>
<b>[08:32] </b><b>TillMossakowski1: </b>Alexander: such a basic
signature could be mapped to a larger signature, where sets, bags
etc. cannot be used as classifiers<br>
<b>[08:33] </b><b>TillMossakowski1: </b>Ed: the type after the
colon has two facets: (1) the type (2) the multiplicity and flags
about orderedness and uniqueness<br>
<b>[08:35] </b><b>TillMossakowski1: </b>fUML does not contain an
axiomatization of enumerations, so we should provide this here<br>
<b>[08:38] </b><b>TillMossakowski1: </b>Alexander: enumerations
could be seen as instance specifications<br>
<b>[08:39] </b><b>TillMossakowski1: </b>but additionally, we
need to require that the enumeration exhausts the whole type<br>
<b>[08:40] </b><b>TillMossakowski1: </b>Ed: enumerations are
specializable<br>
<b>[08:40] </b><b>TillMossakowski1: </b>Ed: but this is
tpye-unsafe, so maybe omit it<br>
<b>[08:42] </b><b>TillMossakowski1: </b>Fabian: class predicates
should be restricted to be unary<br>
<b>[08:51] </b><b>TillMossakowski1: </b>axioms for properties
need to be corrected<br>
<b>[08:51] </b><b>TillMossakowski1: </b>Ed: statically,
compositions may have cycles, but not in the instances<br>
<b>[08:54] </b><b>TillMossakowski1: </b>Michael: cycle check for
compositions could be defind using mereology<br>
<b>[09:00] </b><b>TillMossakowski1: </b>Ed: properties also can
have cardinalities<br>
<b>[09:00] </b><b>MichaelGruninger: </b>I need to leave now -- I
will send the pointers for mereologies later<br>
<b>[09:01] </b><b>TillMossakowski1: </b>bye Michael<br>
<b>[09:03] </b><b>TillMossakowski1: </b>Ed: associations are
predicates of single values, whereas properties can be over sets
etc.<br>
<b>[09:05] </b><b>TillMossakowski1: </b>Aexander: we need to
correct the representation for compositions used in associations<br>
<b>[09:06] </b><b>TillMossakowski1: </b>Ed: (follow up to the
above): multiplicities are different for associations and for
properties, this is a bit tricky<br>
<b>[09:13] </b><b>TillMossakowski1: </b>Terry: please add page
numbers<br>
<b>[09:15] </b><b>TillMossakowski1: </b>Fabian: shouldn't the
stuff we are doing here eventually become part of fUML?<br>
<b>[09:15] </b><b>TillMossakowski1: </b>Ed: it is OK to have
this as part of OntoIOp/DOL<br>
<b>[09:16] </b><b>TillMossakowski1: </b>Ed: as we go forward,
there could be some feedback into fUML, but for now, it should
stay in DOL<br>
<b>[09:17] </b><b>TerryLongstreth: </b>Could the annex be turned
into a paper and published as "an approach"<br>
<b>[09:18] </b><b>TillMossakowski1: </b>next meeting in two
weks, Feb 9, same time<br>
<b>[09:18] </b>List of attendees: Alexander Knapp,
ChristophLange, Ed Seidewitz, FabianNeuhaus, JimLogan,
MichaelGruninger, MihaiCodescu, OliverKutz, TerryLongstreth,
TillMossakowski<br>
</tt>
</body>
</html>