[ontoiop-forum] ontoiop_20150126: Chat Transcript
Till Mossakowski
mossakow at iws.cs.uni-magdeburg.de
Mon Jan 26 18:24:55 CET 2015
*Chat transcript from room: ontoiop_20150126*
*2015-01-26 GMT-08:00*
*[07:59] *anonymous morphed into Ed Seidewitz
*[08:01] **TillMossakowski1: *Ed, Jim, are you on the call?
*[08:02] *anonymous morphed into MihaiCodescu
*[08:02] *anonymous1 morphed into Alexander Knapp
*[08:02] **TerryLongstreth: *there's a term with which I'm unfamiliar:
"abuse of notation"
*[08:03] **TillMossakowski1: *Till presents the slides (sent to mailing
list)
*[08:07] **TillMossakowski1:
*http://iws.cs.uni-magdeburg.de/~mossakow/Slides-OntoIOp.pdf
*[08:14] **TillMossakowski1: *properties only cover query operations,
full operations would lead to state changes
*[08:16] **TillMossakowski1: *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.
*[08:16] **TillMossakowski1: *Fabian: we are following Conrad's proposal
to keep things static
*[08:23] **FabianNeuhaus: *correction on Models via translation slide:
replace "class" by "class or datatype"
*[08:26] **TillMossakowski1: *Ed: you do not have lists or sets in UML,
but the only emerge through ordering properties on associations
*[08:31] **TillMossakowski1: *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.
*[08:32] **TillMossakowski1: *Alexander: such a basic signature could be
mapped to a larger signature, where sets, bags etc. cannot be used as
classifiers
*[08:33] **TillMossakowski1: *Ed: the type after the colon has two
facets: (1) the type (2) the multiplicity and flags about orderedness
and uniqueness
*[08:35] **TillMossakowski1: *fUML does not contain an axiomatization of
enumerations, so we should provide this here
*[08:38] **TillMossakowski1: *Alexander: enumerations could be seen as
instance specifications
*[08:39] **TillMossakowski1: *but additionally, we need to require that
the enumeration exhausts the whole type
*[08:40] **TillMossakowski1: *Ed: enumerations are specializable
*[08:40] **TillMossakowski1: *Ed: but this is tpye-unsafe, so maybe omit it
*[08:42] **TillMossakowski1: *Fabian: class predicates should be
restricted to be unary
*[08:51] **TillMossakowski1: *axioms for properties need to be corrected
*[08:51] **TillMossakowski1: *Ed: statically, compositions may have
cycles, but not in the instances
*[08:54] **TillMossakowski1: *Michael: cycle check for compositions
could be defind using mereology
*[09:00] **TillMossakowski1: *Ed: properties also can have cardinalities
*[09:00] **MichaelGruninger: *I need to leave now -- I will send the
pointers for mereologies later
*[09:01] **TillMossakowski1: *bye Michael
*[09:03] **TillMossakowski1: *Ed: associations are predicates of single
values, whereas properties can be over sets etc.
*[09:05] **TillMossakowski1: *Aexander: we need to correct the
representation for compositions used in associations
*[09:06] **TillMossakowski1: *Ed: (follow up to the above):
multiplicities are different for associations and for properties, this
is a bit tricky
*[09:13] **TillMossakowski1: *Terry: please add page numbers
*[09:15] **TillMossakowski1: *Fabian: shouldn't the stuff we are doing
here eventually become part of fUML?
*[09:15] **TillMossakowski1: *Ed: it is OK to have this as part of
OntoIOp/DOL
*[09:16] **TillMossakowski1: *Ed: as we go forward, there could be some
feedback into fUML, but for now, it should stay in DOL
*[09:17] **TerryLongstreth: *Could the annex be turned into a paper and
published as "an approach"
*[09:18] **TillMossakowski1: *next meeting in two weks, Feb 9, same time
*[09:18] *List of attendees: Alexander Knapp, ChristophLange, Ed
Seidewitz, FabianNeuhaus, JimLogan, MichaelGruninger, MihaiCodescu,
OliverKutz, TerryLongstreth, TillMossakowski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.ovgu.de/pipermail/ontoiop-forum/attachments/20150126/0056a67a/attachment.html>
More information about the ontoiop-forum
mailing list