John, (01)
Thanks for those comments - replies interleaved below... (02)
John F. Sowa wrote: (03)
>Mike,
>
>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
Director
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)
|