<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <tt>
      <b>Chat transcript from room: ontoiop_20150209</b><br>
      <b>2015-02-09 GMT-08:00</b><br>
      <b>[07:58] </b><b>TillMossakowski: </b>please find the slides at
      <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:00] </b>anonymous morphed into FabianNeuhaus<br>
      <b>[08:01] </b><b>TillMossakowski: </b>anyone on Skype?<br>
      <b>[08:02] </b><b>TerryLongstreth: </b>I'm trying to get off of
      another conference, will dial in shortly.<br>
      <b>[08:03] </b>anonymous morphed into Conrad<br>
      <b>[08:04] </b><b>ChristophLange: </b>Hi all, UML is not my
      field, but @TillMossakowski I will look into Ontohub issue 1066
      meanwhile.<br>
      <b>[08:11] </b><b>TillMossakowski: </b>Conrad: operations should
      not be subsumed under the term "properties".<br>
      <b>[08:11] </b><b>TillMossakowski: </b>Alexander: why not stick
      to UML terminology and speak of attributes and (query) operations?<br>
      <b>[08:12] </b><b>TillMossakowski: </b>Alexander: the parameters
      of the operations are also of form tau[c]<br>
      <b>[08:14] </b><b>Alexander Knapp: </b>We should change the
      property declaration into an operation declaration (for queries):
      c.o(x_1 : \tau_1[c_1], \ldots, x_n : \tau_n[c_n]) : \tau[c'] for
      operations; c.p : \tau[c']<br>
      <b>[08:15] </b><b>TillMossakowski: </b>properties are just c.p :
      tau[c']<br>
      <b>[08:16] </b><b>TillMossakowski: </b>i.e. attributes<br>
      <b>[08:16] </b><b>TillMossakowski: </b>are multiplicities
      allowed in return values of operations?<br>
      <b>[08:18] </b><b>Alexander Knapp: </b>Operations could have out
      or in-out parameters; check whether this is possible also for
      query operations. Check whether return parameters are unique.<br>
      <b>[08:21] </b><b>TillMossakowski: </b>compositions are
      separated from normal properties, because they have a special
      semantics<br>
      <b>[08:22] </b><b>Alexander Knapp: </b>Stick with the current
      UML2 terminology.<br>
      <b>[08:25] </b><b>Alexander Knapp: </b>"A single parameter may
      be distinguished as a return parameter" (UML Superstructure
      Specification 2.4.1, p. 123)<br>
      <b>[08:28] </b><b>TillMossakowski: </b>Composites are always
      binary. In associations we do not cover composites, just specify
      the owner roles.<br>
      <b>[08:31] </b><b>Alexander Knapp: </b>Make it possible to have
      associations for declaring two properties as inverses of each
      other.<br>
      <b>[08:37] </b><b>TillMossakowski: </b>The meta-properties
      should be better explained in the document.<br>
      <b>[08:37] </b><b>Alexander Knapp: </b>Introduce "annotations"
      not for classifiers, but for properties to make clear their
      intention.<br>
      <b>[08:40] </b><b>Alexander Knapp: </b>Choose different names
      for associations in Fig. E.1.<br>
      <b>[08:48] </b><b>TillMossakowski: </b>Alexander: the semantics
      of an association is a set of individuals (not of sets, bags
      etc.).<br>
      <b>[08:49] </b><b>TillMossakowski: </b>But if you have a binary
      association, and fix one of the ends, you get a function with a
      type, and this type may involve sets, bags etc.<br>
      <b>[08:50] </b><b>Conrad: </b>See semantics of associations in
      11.5.3, especially the paragraph beginning "For an Association
      with N memberEnds".<br>
      <b>[08:51] </b><b>Conrad: </b>From the UML spec: For an
      Association with N memberEnds, choose any N-1 ends. Let the
      Property that constitutes the other end be called oep, so that the
      Classifiers at the chosen N-1 ends are the context for oep (see
      9.5.3). Associate specific instances with the context ends. Then
      the collection of links of the Association that refer to these
      specific instances will identify a set of instances at oep. The
      value represented by oep (see 9.5.3) is a collection calculated
      from this set as follows: All of the instances in the set occur in
      the collection, and nothing else does. If oep is marked as unique,
      each instance will occur in the collection just once, regardless
      of how many links connect to it. If oep is marked as nonunique,
      each instance will occur in the collection once for each link that
      connects to it. If oep is marked as ordered, the collection will
      be ordered in accordance with the ordering information in the
      links. The cardinality of this collection is its size. The
      multiplicity of oep constrains this cardinality, or in the case of
      qualified associations, the size of the collection partition that
      may be associated with a qualifier value.<br>
      <b>[08:51] </b><b>TillMossakowski: </b>hence, the semantics of
      associations is not just a set of tuples, but also contains
      additional information giving the order in the sequences etc.
      obtained in this way.<br>
      <b>[08:54] </b><b>TillMossakowski: </b>Fabian: the semantics
      could be defined as a set of functions (say, from signals to
      tau[tracksetion] and vice versa) that enjoy the property that each
      function leads to the same set of tuples.<br>
      <b>[08:56] </b><b>Conrad: </b>Confirming Till's comment "hence"
      above, from UML spec: When one or more ends of the Association are
      ordered, links carry ordering information in addition to their end
      values.<br>
      <b>[08:57] </b><b>TillMossakowski: </b>Alexander: the ordering
      in the lists that you get are completely unspecified. Hence, you
      can get the projection functions to list by just returning the
      set, arbitrarily converted to a list<br>
      <b>[08:59] </b><b>Conrad: </b>Conrad: The ordering of property
      values isn't arbitrary. UML has actions for adding values at
      certain points in a list. Getting values from a property will
      reflect the way they are added.<br>
      <b>[08:59] </b><b>Alexander Knapp: </b>Thanks, Conrad. We'll
      have to add at least a comment to this effect.<br>
      <b>[09:01] </b><b>TillMossakowski: </b>where is buml:Sequence
      specified?<br>
      <b>[09:01] </b><b>TillMossakowski: </b>Conrand: this is probably
      a typo<br>
      <b>[09:02] </b><b>MichaelGruninger: </b>need to leave now ...<br>
      <b>[09:24] </b><b>TillMossakowski: </b>corrected slides:
      <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>[09:27] </b><b>FabianNeuhaus: </b>sorry, I will have to go
      soon. I have some new feature requests for DOL, but I do that on
      the email list<br>
      <b>[09:30] </b><b>Alexander Knapp: </b>Composite aggregation is
      a strong form of aggregation that requires a part instance to be
      included in at most one composite at a time (UML Superstructure
      2.4.1, p. 38).<br>
      <b>[09:36] </b><b>TillMossakowski: </b>Conrad: one and the same
      track can own one and the same signal through different
      composition relations. Hence, the axiom on slide 13 can stay as it
      is.<br>
      <b>[09:43] </b><b>TillMossakowski: </b>p.16, last axiom: needs
      to be reformulated: (r x z), and (member y z)<br>
      <b>[09:46] </b><b>TillMossakowski: </b>Fabian: use different
      variables for sets and individuals<br>
      <b>[09:46] </b><b>Alexander Knapp: </b>Multiplicity constraints
      for composite properties better without a special "!"<br>
      <b>[09:50] </b><b>Alexander Knapp: </b>Sorry, I have to leave,
      trying to catch my train... Thanks for the comments!<br>
      <b>[10:06] </b><b>TillMossakowski: </b>We should try to complete
      the UML to Common Logic translation until Feb 23. Then my student
      Martin Glauer will have enough time to implement the translation
      into Hets before the OMG meeting (which starts on March 23).<br>
      <b>[10:07] </b><b>TillMossakowski: </b>next meeting: Feb 23,
      same time. Topic is third iteration of the UML to Common Logic
      translation.<br>
      <b>[10:07] </b>List of attendees: Alexander Knapp,
      ChristophLange, ConradBock, FabianNeuhaus, MichaelGruninger,
      OliverKutz, TerryLongstreth, TillMossakowski, MihaiCodescu<br>
    </tt>
  </body>
</html>