[Top] [All Lists]

Re: [ontolog-forum] Foundation ontology [was How not to write specificat

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Mike Bennett <mbennett@xxxxxxxxxxxxxxx>
Date: Tue, 26 Aug 2008 18:36:45 +0100
Message-id: <48B43F2D.7090009@xxxxxxxxxxxxxxx>
John,    (01)

Thanks for those comments - replies interleaved below...    (02)

John F. Sowa wrote:    (03)

>I agree that it's important not to scare people:
>MB> This is in line with trying to come up with a way of
> > presenting business "facts and things" in a way that does
> > not scare away business people.
>Or better, it's important to present the material in a way that
>is intelligible to the domain experts, who may know a great deal
>about the subject matter, but not about arcane notations.
Exactly. A lot of technical people find it hard to distinguish between 
intelligence and knowledge, with the result that they either baffle or 
insult the business domain expert, or frequently both.    (04)

This is a common bug-bear of mine, as my background is engineering 
management and QA, i.e. how development is carried out. The art of 
having technology-neutral descriptions of requirements, that can be 
validated (and future changes validated) by business people, is one 
which too many computer technical people do not grasp, and which 
business people see as a technical issue and refuse to own. There is 
well-established but little-understood theory on requirements 
management, and to me the whole semantics question is equivalent to 
formal requirements, it specifies in a technology-neutral sense what 
data should be about, in the same way as a requirements statement states 
in a technology-neutral way what a program should do. So that's where 
I'm coming from.    (05)

I tend to describe the challenge in terms of a "Language interface". I 
don't care if the business person claims to be able to write SQL 
statements or the technical person claims to understand structured 
derivatives products trading. Either way, the "business" stuff should be 
written in a business language, and the technical stuff in a technical 
language, with some procedural or other linkage between them - 
especially if the thing in question is to have a life and therefore 
future changes. Too many industries (expecially financial) suffer from 
the "hero" culture where the person doing a job is expected to do 
everything right without review or input from others. The engineering 
and petrochemical companies have it right I think, the procedures do the 
work so as not to rely on the individuals. Much safer. Sadly our money 
is not in such safe hands as our oil.    (06)

So it's not really a matter of "scaring" or otherwise, though we often 
describe it as such to the business people so they know we are comitted 
to not baffling them with technical stuff.    (07)

Unfortunately to some business people (usually the pointy-haired 
variety, as per Dilbert), anything at all complex is regarded as 
"technical". You have to get past these people to the real experts, who 
are always glad to deal with complexity as long as it does not involve 
learning a new language. So far this has meant spreadsheets almost 
exclusively, as being the only complex structured interface that 
everyone is familiar with. Once the business expert realises that what 
you are showing them is a view of their world, and not some new 
technical format you have thought up, then their eyes light up.    (08)

So I have tried to make a commitment that instead of seeing OWL, they 
are seeing "Facts and Things". I also did diagrams which were 
language-neutral, but everyone on the project team (except me) took the 
view that only technical people would look at diagrams, so we default to 
the more language-rich diagram now. In fact regardless of their job, 
some people have primary visual modality and think in diagrams, while 
others have primary audial modality and think in words. Unfortunately 
most people think that most people are like them.    (09)

>That is one reason why I have emphasized the need to use controlled
>natural languages for specifying ontologies.  If you click on any
>of the headings under the phrase "Global terms" at the bottom of
>your web site,
>    http://www.hypercube.co.uk/edmcouncil/
>you will notice a lot of English words and phrases.  But such
>words and phrases are comments that are ignored by the software.
>With minor modifications, those words and phrases could be written
>in controlled English that a computer can map to a formal notation,
>such as Common Logic.
Indeed. I was conscious, in defining the relationships, that they could 
potentially be read in this way, though I have experimented with various 
different approaches so there is not one single approach. I was 
originally going to have [Domain][relationshipName][Range] as 3 separate 
parts of the Object Property name (using the 3 parts of the underlying 
UML Association) but I changed it to single-string relationship names to 
make the spreadsheet / report more intuitive. I also looked at two 
approaches for the names - one using the OWL style of hasThis, hasThat 
etc, which causes bafflement when seen in a "Terms" spreadsheet, and one 
which is just the name of the relationship without the "has" - 
particularly with the high level archetypes like Role. The latter 
approach can cause relationships to be ambiguous as to direction - is 
"Underwriter" a hasPart or an isPart relationship? i.e. does the party 
which is an underwriter point to or from the thing that is underwritten 
(is it the domain or the range of the Underwriter relationship?). An 
alternative which I haven't done here is to separate the verb (has, is) 
into its own field / tag, followed by the name of the kind of thing that 
it is, as part of the relationship (not the range). i.e. 
[verb][relation] followed by the actual range class as the range.    (010)

So these are issues which are left open in the current iteration of the 
repository, and which I hope to fine tune around what makes sense to 
business subject matter experts, but with one eye on how this can be 
used in the world of machines as well.    (011)

You have probably noticed that, independently of the labels on the 
relationships themselves, I've followed a relatively consistent notation 
on the blue (UML association class) boxes that are the classes for the 
object property hierarchy (these don't appear in tables and reports). By 
concatenating (by hand) the domain, relationship and range, and 
eliminating duplicate words, I have something which is surprisingle 
close to a readable English, which I was quite pleased about. Again I 
have not settled on one globally consistent approach for this yet.    (012)

>For some discussion of controlled English with examples of
>medical "English", as written by a physician, and its mapping
>to controlled English (by a human editor) and then by computer
>to Common Logic, see the following slides:
>    http://www.jfsowa.com/talks/cl_sowa.pdf
>See slide 5 for a diagram that shows the role of Common Logic
>(with the three dialects CLIF, CGIF, and XCL) as an intermediate
>notation between controlled English and a variety of computer
>oriented notations, including RDF and OWL.  Adam Pease has been
>using controlled English as a supplement to the SUMO axioms.
>Slide 8 is a cautionary note that makes the point that writing
>controlled English requires some training.  But anyone who can
>read English and is familiar with the subject matter can read
>controlled English about that subject.
>Slide 15 shows some so-called "English" written by a physician.
>The next few slides show a systematic translation of that text
>by a human editor (namely, me) and the CLIF translation.
>Slide 21 shows the complete version written in controlled English,
>Slide 22 shows the complete CLIF translation, and Slide 23 shows
>the equivalent translation in CGIF.  Note that each of them fits
>on a single slide.  Another person had used OWL to express that
>same medical English, but the results took many, many pages,
>and even a graphical display would not be humanly readable.
I remember you made that point at the Semantics Technology conference, 
focusing exclusively on OWL as text. You now say "even" a graphical 
display, but I think the important point (to me at least) is that you 
should never even think of putting some OWL XML text down on a page and 
saying "here is the model in OWL".    (013)

This is why I have been looking for a format that allows a good, 
technology-neutral graphical display of meaningful information. Protege 
does not give you that. TopBraid composer comes closer, but does not 
give you enough control over the diagrams (though it has come a long 
way). The only way (in my humble opinion) to have a useful graphical 
display of something meaningful is to separate the graphic from the 
model and then be able to display as much or as little of the model as 
you like on a given diagram. So far, I only know of UML that does that, 
which is why I have been using a UML tool to do it. One day the OWL 
tools will give a usable business subject matter expert graphical 
capability, but it seems that the designers of these things need to be 
pushed to do that. It's the language interface again.    (014)

Of course conceptual graphs already satisfy the need for a graphical 
notation, if there are tools that allow you to put fragments of these 
onto the page as in UML. I'm not sure if business people can review and 
validate them without a knowledge of the underlying logic though. I 
would be interested to see how domain experts interact with these.    (015)

I will be disappointed if we don't get to a point where meaningful 
information can be described both graphically and in words, equally and 
from the same underlying model (separating form from content), so that 
all kinds of business mind can input, review and validate. First we have 
to persuade the more arrogasnt techies that some business people can 
think in diagrams too.    (016)

>The remaining slides discuss various issues, and Slide 28 has
>URLs for further reading.  One of the pointers is to the ACE
>web site, which has a free, open source, downloadable version
>of controlled English.
Excellent - thanks for that. I will look into this. I also intend to 
look into how SBVR (Semantics of Business Vocabulary and Business Rules) 
might fit into this equation. The current iteration of the repository 
didn't really have the budget to extend beyond tables and diagrams but I 
would like to put some kind of verbal layer on somehow, if I can find 
the budget for it. But I will be looking into this as soon as I have 
completed the current iteration.    (017)

>I believe that we should make controlled English a requirement
>for the Foundation Ontology:
Agreed in principal. As something that is a point of reference for a 
wide range of things I would think this is vital.    (018)

>  1. Every formal axiom, rule, or definition should be accompanied
>     by an equivalent statement in some version of controlled English.
Automatically generated somehow so that it's clear that any changes in 
the model content are accompanied by reliably equivalent changes in the 
controlled English.    (019)

What about classes? At the moment in the EDM Repository we have (to be) 
peer-reviewed business definitions, which everyone agrees on whether or 
not they understand the accompanying logical structure of the model. 
This is a non negotiable requirement. Effectively this is grounding the 
meaning of each individual term to the accompanying meanings in the mind 
of the reader, independently of model semantics.    (020)

>  2. The formal statement and the controlled English statement should
>     be automatically checked for equivalence.  That could be done
>     either by automatically translating the controlled English
>     to the formalism or by using a suitable theorem prover.
Agreed - as above, I think this is vital for change management. You 
can't have (1) without (2).    (021)

>  3. The metalanguage commentary about the formal specification
>     should also be written in controlled English.
That would be interesting. But less critical than (1) and (2).    (022)

>These requirements would enable domain experts to read specifications
>and check whether they really correspond to what they had told the
>knowledge engineer (or whoever had written the spec's).
Absolutely. And review any changes and additions as time goes on. All 
this should fit into the box marked "requirements management" in the 
formal development processes that people should have in place if they 
are going to use any of this stuff successfully.    (023)

Best regards,    (024)

Mike Bennett    (025)

>John Sowa
>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
>Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>    (026)

Mike Bennett
Hypercube Ltd. 
89 Worship Street
London EC2A 2BF
Tel: 020 7917 9522
Mob: 07721 420 730
www.hypercube.co.uk    (027)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (028)

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