Mike, (01)
I would agree with that point, at least for the versions of
semantics that are useful for computer applications: (02)
MB> ... 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. (03)
I was one of the "early adopters" of the word 'ontology' for
computer specifications back in 1983. But if I had realized how
loosely it was going to be bandied about, I would have avoided it. (04)
MB> ... 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. (05)
I agree, and I would add that there is no one-size-fits-all notation
that is ideal for all purposes. (Natural languages come closest to
being universal, but they can also benefit from supplementary info
from diagrams, tables, etc.) (06)
MB> 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. (07)
That is certainly true. I like to cite musical notation as a highly
sophisticated notation with good human factors, yet as unambiguous as
any version of logic. It also has both linear and graphical aspects.
It takes some practice to learn, but someone who has learned it can
read it at high speed. Furthermore, the development of the musical
forms we hear all the time would have been impossible without it. (08)
MB> By concatenating (by hand) the domain, relationship and range,
> and eliminating duplicate words, I have something which is
> surprisingly close to a readable English, which I was quite
> pleased about. (09)
The only thing I would disagree with is the adverb "surprisingly".
There are systematic patterns underlying natural languages, and
a good design methodology should take advantage of them. That
same methodology can include appropriate information to enable
the tools to generate *both* controlled English and a more
conventional computer-oriented notation. (010)
MB> 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". (011)
I completely agree. For the ISO standard for Common Logic, the
body of the standard specifies the semantics in terms of an abstract
syntax that is independent of any concrete notation. The three
annexes specify three different concrete syntaxes (CLIF, CGIF,
and XCL), but we *encourage* anyone to define their favorite
notation, linear or graphic, as a concrete dialect of CL. (012)
MB> 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. (013)
All the required definitions that could be stated in any version of
logic could be stated in controlled English. Talking about "meanings
in the mind" always leads to endless philosophical discussions. One
reason why I like to use controlled English is that we can focus on
"meanings on the page" as stated in a notation that everybody can read. (014)
John (015)
_________________________________________________________________
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 (016)
|