Re: [ontolog-forum] UML and Semantics

[William Frank <williamf.frank@xxxxxxxxx>]

Thanks for this, Ed.  Especially something I had not noticed about my "departure."  I am happy to knowingly violate UML semantics, but not to do so in ignorance.  See below.

On Wed, Dec 5, 2012 at 2:55 PM, Barkmeyer, Edward J <edward.barkmeyer@xxxxxxxx> wrote:

Here and there a supporting comment.

 

William Frank wrote:

 

So now, I WRITE "at least one" more than one, etc.   Right on the UML diagram, when multiplicity is an issue. 

 But when you depart, you will lose the UML-educated audience.

Not if you explain that is what you are doing.  And mostly, the words are just to annotate obscure symbols.  For example, I will write, alongside a black diamond, "contains", or whatever fits.

[EJB] The problem with UML in this regard is that it defaults to a constraint.  The interpretation of an association end that has no stated multiplicity is ‘exactly one’. 

Ah, I did not know that.   That you so much for pointing this out.
 

This is a part of the object-oriented programming background.  The proper default for relationships is 0 or more,

I would even more prefer "unknown", though mathematically equivelent to the default.   Defaults, as a policy, are dangerous.
 

unless the modeler says it is constrained.  But 0 or more is harder to implement in an OOPL – you have to pick a paradigm for arrays or lists.

 The place I know I am violating the semantics of UML is that I use a 'navigation" arrow to be a reading arrow, since few tools give you the reading arrow, and people like to see how they are supposed to follow the diagram, along the arrows.   But except for some purists, when I explain this to "UMLers, the don't mind.

[EJB] I have a largely negative reaction to the idea that language syntax should enforce “good” modeling practice.  Language syntax should ENABLE _expression_ of intent and PERMIT good modeling practices.  The bitter lesson is that “good practice” in modeling Java programs and “good practice” in modeling databases and “good practice” in modeling the problem space may be different and conflicting. 

Absolutely.   I have found the same thing in constructing a knowledge sharing environment on a Wiki.  Many people want you to ENFORCE all kinds of processes, ("you can't talk about that until you have talked about this other first.")
 
So, don't compare your good practice in one language with other people's poor practice in another.  And don't compare your work as an individual to the work of a standards body. Apples and apples, please.

I agree with Edward that NIEM/ORM is much better than either of them in expressing the semantics of the world, but he is right that they aren't well enough supported.

I agree with you both here, but there is alot you can do that his consistent with UML, not just FrankML, that looks like this. 

For example:

there exists a SubscriptionRelationship

such that

William

is

subscriber-in-the-SubscriptionRelationship

and

the Wall Street Journal

is

provider-in-the-SubscritionRelationship


or

there exists a

Height

siuch that
William

has

the Height

and the value of the height

is

six feet.


This does not presuppose an implementation predjudcie toward attributes and associations.   And, I am pretty sure it is valid UML semantically.   As you suggested in an early post, Ed, we need to have syntactic bindings like is, have, ...,  in English, while in other languages, they might be positional , and in yet others change the forms of the contentufl words themselves.

As would actions, in

there exists a Subscribing such that  William ... , and the New York Times ----,

Following the Davidson patterns that John Sowa was recently showing us.

[EJB] In my experience the relationship between object-oriented analysis and object-oriented programming differed widely among the authors who wrote about o-o analysis.  I mentioned once to Steve Mellor that I found the Shlaer-Mellor book interesting, and Steve responded “interesting that the two authors clearly disagreed on the meaning of the title”.
 

[EJB]  I would say rather that, if the intent of the formal model is to produce an implementation by rote transformation, then the model is an implementation model.”  And I think David, William, John and I are all in agreement on that part.

I even think Steve Mellor would agree, with the word 'rote" included. 

[EJB] I see, however, that some of our educated journeyman knowledge engineers think that a good OWL model is one that allows the chosen reasoner to do the test classifications quickly.  It is just another version of making the problem space model the solution model, because the OWL model is the implementation schema.  A clear axiomatic representation of a problem space may need to be restructured, simplified, and assisted with helper axioms and other controls to produce an efficient “theory” for a particular kind of use by a particular reasoner.  Knowledge engineering is an engineering activity, and like the others it has both analytical and solution models.  We should not again make the mistake of assuming that a good analytical OWL model can be judged by the performance of a reasoner.

Ah, this is another deeper level of this matter.

 

-Ed

 

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
 

-- 
William Frank

413/376-8167

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (01)