Bill Burkett wrote:
> Chris, Ed:
>
> I disagree that an ontology is (1) an artifact and (2) is something that can
>be engineered. (Thus I support Peter's question of whether "ontology engineer"
>is a useful term.) It is the *representation/manifestation* of an ontology
>that is the artifact that is created - it's the OWL representation (or CL
>representation or whatever) that is the artifact. (01)
This is a subject that has been discussed in this forum before. I hold
with those who believe the ontology is the artifact -- the captured
knowledge. Captured knowledge has a form of expression. Knowledge that
is without external form is not an 'ontology'. Knowledge whose external
form is not 'suitable for automated reasoning' is not an 'ontology'.
That is the difference between an 'ontology' and an XML schema, or a
Java program (perhaps), or a PDF text, or a relational database. (02)
The OWL formulation is an ontology; the CL formulation is an ontology;
they are different ontologies, even when both are said to represent
exactly the same knowledge. If they do represent exactly the same
knowledge, they are "equivalent". (03)
I am indebted to Professor Hyunbo Cho for the characterization of
uncaptured knowledge as "unknown knowledge" -- a fitting oxymoron. (04)
> There is also the intangible aspect of what the representation of the
>ontology means that not subject to engineering discipline, but rather depends
>more on individual interpretation and perspective. (05)
Which is only to say that the formulation of the captured knowledge has
some level of residual ambiguity. One must realize, however, that
perspective often adds relationships of concepts in the ontology to
concepts that go beyond the scope of the ontology, and such differences
in perspective may not lead to any difference in the interpretation of
the concepts in the ontology per se. (06)
In fairness, the biggest issue in most ontologies is the number of
primitive concepts -- concepts whose definitions are written in natural
language and are formally testable only to the extent of the axioms
provided for them, if any. Primitive concepts usually leave much to the
intuition of the human reader. OTOH, there are a number of 'primitive
concepts' in Cyc that are so strongly characterized by axioms that it is
difficult to imagine anyone misunderstanding what was meant -- a false
intuition will quickly lead to a contradiction. (07)
> An ontology is not like a chair or a car or a building that is engineered to
>meet specific, concrete, physical requirements, and can be measured whether or
>not it meets those requirements. (08)
Rich Cooper answered that: (09)
> I emphatically disagree! If the ontology doesn’t meet a specific set
> of needs, whether documented as requirements or some other
> documentation method, the need drives the usage. If there are no
> needs, the ontology stays in the college or academy where it was
> originated or partnered with.
>
> Requirements, i.e. real human needs, always drive the market.
> (010)
My sentiments exactly. (011)
I agree that a lot of what is published as ontologies is academic toys,
but that has been true of all kinds of software for 40 years, and it is
not restricted to software artifacts. Rich is right. Commissioned
ontologies have a functional purpose; otherwise there would be no
investment. The purpose of most academic stuff is to learn the trade,
and get a degree by pretending to model a real domain, and in the
process learning about the ugliness of reality. Civil engineers build
concrete boats, or cardboard ones. MEs build fighting robots. (012)
> While I agree that training and experience can make one a better ontology
>designer, I don't think it's possible to completely remove individual bias
>from the process.
> (013)
Well, that depends on what the process is. If you have one knowledge
engineer working with one or more domain experts, and the result is
nominally a consensus model, it will be biased by the opinions in the
room that are backed by the most personally or politically powerful
individuals, like any other such effort. And the sole ontology engineer
is in a position of some power. But if that result is subjected to a
fair and open review process, by peers of the knowledge engineer and
peers of the domain experts, a lot of the biases are exposed and
eliminated. That is, we are talking about what the engineering practice
is. (If we start by saying this is not engineering, the practitioners
will never be forced to consider what good practice for their trade
might be.) (014)
-Ed (015)
> Bill
>
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
>[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ed Barkmeyer
> Sent: Tuesday, January 11, 2011 2:57 PM
> To: [ontolog-forum]
> Subject: Re: [ontolog-forum] I ontologise, you ontologise, we all mess up...
>(was: Modeling a money transferring scenario, or any of a range of similar
>dialogues)
>
> +1
>
> I was about to write almost exactly what Chris wrote below. An ontology
> is an artifact that performs a function. Engineers design artifacts
> that perform functions. Thus the term.
>
> Peter is right that 'ontology engineers' and 'knowledge engineers' and
> 'computer systems analysts' may tend to inject their ideas and
> misunderstandings into their artifacts. But part of that is that
> encoding knowledge involves a certain amount of understanding of that
> knowledge by the knowledge engineer. There is a fine line between
> rephrasing what you think was said for the purpose of clarifying what
> the expert said, and injecting your own understanding into the model.
> The related problem is the erroneous belief that your technology is
> powerful enough to represent exactly the knowledge that is needed, which
> causes you to dismiss what you don't know how to represent, as opposed
> to wondering whether your product will be able to perform the intended
> function.
>
> I repeat what I said earlier about the hubris of engineers -- many
> engineers think they can quickly master any related subject sufficiently
> for their work, and knowledge engineers are no exception. Like any
> trade, there is a spectrum of competence, and the high end practitioners
> are experienced enough to know when they are out of their depth. (As a
> journeyman software engineer working with a physicist to debug a
> program, I pushed deeper and deeper into the mathematics. At some
> point, the physicist said to me, "I don't know how much nuclear magnetic
> resonance I can teach you in an hour!" Point taken!)
>
> -Ed
>
> "The greatest enemy of Knowledge is not Ignorance,
> it is the Illusion of Knowledge."
> -- Stephen Hawking
>
>
>
>
> Christopher Menzel wrote:
>
>> On Jan 11, 2011, at 1:49 PM, Peter Brown wrote:
>>
>>
>>> ...
>>> I remain baffled by the terms (and the presumed concepts behind them -
>which are *not* clear at all) of 'ontology engineer' and 'ontology
>engineering'. I do not think that one can 'engineer' an ontology any more than
>one can engineer a meeting: one can bring skills, methods and tools to the
>meeting (as Chair of a meeting for example) and can make sometimes significant
>progress even in ignorance of the subject of the meeting - if the purpose of
>the role of Chair is to help the meeting to come to some conclusion. However,
>once a Chair starts to pronounce on matters and get involved in the substance
>of a meeting, those skills and methods become overshadowed by their ignorance
>or partisanship.
>>>
>>>
>> Hello Peter,
>>
>> I don't understand your analogy. An ontology is a concrete artifact (unlike
>a meeting). And, like the production of any quality artifact, the production
>of a good ontology requires training and expertise. On the face of it,
>anyway, "ontology engineer" seems a reasonable title for those with the
>appropriate training and expertise. (Opinions vary, of course, regarding the
>nature and extent of such training and expertise.)
>>
>> I have to say that I don't see how an ontology is in any way enough like a
>meeting to support your argument that, because it makes no sense to engineer a
>meeting, it makes no sense to engineer an ontology.
>>
>> -chris
>>
>>
>> _________________________________________________________________
>> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>> Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>>
>>
>>
>
> (016)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 (017)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (018)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (019)
|