Hi Ed, (01)
Are we to the point yet where a "final" draft of the proposed program or
work can be circulated that addresses the email discussion points? (02)
My one comment : If we can agree to your proposal and use CLIF, OWL and
informative UML diagrams, then why do we need a language selection
committee? (03)
Thanks for making things happen,
David (04)
On Mon, 2009-07-13 at 16:51 +0100, Mike Bennett wrote:
> Hi Ed,
>
> On your point (1), that's more or less exactly what I have done,
> following the excellent standardisation of this for OWL from the OMG.
> Hence my curiousity.
>
> On (2) I think we may differ. However a detailed exploration of that
> would be a paper I've been intending to write up as soon as I get a chance.
>
> I'm certainly happy to put my name down for some effort in this direction.
>
> Best regards,
>
> Mike
>
> Ed Barkmeyer wrote:
> > Mike Bennett wrote:
> >
> >
> >> That sounds great. Can you generate it from the output of a UML model?
> >> How does it compare with what I've done at
> >> www.hypercube.co.uk/edmcouncil which aims to fulfil that exact same
> >> requirement from within UML but is by no means perfect?
> >>
> >> Mike
> >>
> >>
> >
> >
> >>>> [EB] The trick is not to be excessively geeky. My late mentor, Dr.
>Selden
> >>>> Stewart, once observed that all modeling languages are BLAs -- boxes,
> >>>> lines and annotations. As long as you stick with class boxes/balls,
> >>>> association/property lines/wires, and text labels (annotations), you
> >>>> don't violate the "anti-technical" prejudices of "business persons".
> >>>>
> >>>>
> >>> [MW] OK. If that is your objective then I will throw what was originally
>(as
> >>> far as I know) the CDIF (CASE Data Interchange Format) notation into the
> >>> ring. This consists of named boxes for classes/entity types and named
>arrows
> >>> for relationships/relations, where the direction of the arrow tells you
> >>> which direction to read the relationship name in (and nothing else). So
>you
> >>> could have:
> >>>
> >>> A --part of--> B, or
> >>> A <--has part-- B
> >>>
> >>> My experience is that this notation is not only very simple, but very easy
> >>> for anyone to read.
> >>>
> >
> > Indeed. Three points:
> >
> > (1) This is essentially the notation one sees in Protegé. And you can
> > clearly generate a very similar notation with a UML tool, by
> > a) making one end of the association non-navigable, and
> > b) naming the other, or naming the association by the verb
> > This is in fact common practice for people modeling Java in UML. The
> > advantage of UML tools, including some free ones, over Powerpoint and
> > Visio is that they generate a (more or less) standard machine-readable
> > XML form, which can be converted to OWL, for example, with some readily
> > hacked tool. (I already have 3 or 4 such things.) The advantage of
> > Protegé is that it can generate OWL and a proprietary axiomatic text
> > form (which we could also hack). (Student projects)
> >
> > (2) I stand by my claim that the audience for the would-be standard is
> > knowledge engineers, not business people. If we lose sight of that, we
> > will find ourselves making a weak and deliberately inaccurate ontology,
> > because "business people don't understand concept X that way" or
> > "business people won't understand such a complex model". (I have
> > recently worked with a group like that, and it wasted two years of my
> > time.) So the graphical model is a sketch of the ontological
> > relationships, which should be _correct_, but not necessarily
> > "complete". We must stand by the Einstein razor: "We should make things
> > as simple as possible, but no simpler."
> >
> > (3) Matt doesn't mention the CDIF notation for "subtype"/subsumption.
> > This is a foundational concept in OWL, and it is very important to
> > modeling measurement concepts. In particular, every 'measurement unit'
> > is_a 'quantity'. I would be wary of a notation like:
> > measurement-unit -- is a --> quantity
> > because it makes the notation ambiguous. 'is_a' is a class-to-class
> > relationship, rather than an instance-to-instance relationship (like
> > 'part of'). It models an axiom, not just a relation. That is:
> > A -- is part of --> B
> > models a relation "is part of" whose domain is things that satisfy
> > relation (class) A, and whose range is things that satisfy relation B --
> > a vocabulary item. It has two free variables. Whereas,
> > A -- is a --> B
> > models a proposition, a statement: Every A is a B. Formally,
> > (forall x) (if (A x) (B x))
> > It has no free variables. And the model asserts that proposition,
> > making it an axiom.
> > So I would object to overuse of the arrow notation, if it leads to such
> > an ambiguity.
> >
> > And finally, I did say that we need a language-selection committee. I
> > didn't volunteer to lead it, precisely because we need some persons with
> > more knowledge of the ontological Tower of Babel. We seem to have
> > volunteers in the persons of Messrs. West, Bennett, and Walker. ;-)
> >
> > -Ed
> >
> >
> >
>
>
--
UK +44 20 8747 3900
Mobile +44 7788 561308
Skype +1 336 283 0606 (05)
Eurostep Limited. Registered in England and Wales No.03049099
Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ. (06)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/uom-ontology-std/
Shared Files: http://ontolog.cim3.net/file/work/UoM/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard (07)
|