uom-ontology-std
[Top] [All Lists]

Re: [uom-ontology-std] UoM ontology standard - a proposed program of wor

To: uom-ontology-std <uom-ontology-std@xxxxxxxxxxxxxxxx>
From: David Price <david.price@xxxxxxxxxxxx>
Date: Mon, 13 Jul 2009 17:05:02 +0100
Message-id: <1247501102.4247.79.camel@xxxxxxxxxxxxxxxxxxx>
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)

<Prev in Thread] Current Thread [Next in Thread>