[Person-ontology] OWL for exchanging ontologies

Pat Hayes phayes at ihmc.us
Mon Oct 29 10:58:41 PDT 2007


>Hi Pat
>
>thanks for the insights below. I agree in principle with most of what you say

Your training in management is beginning to show. 
Why do I feel like I'm being manipulated? :-)

You are being far too nice to me. I recognize the 
signs. You will superficially agree with me, not 
be 'confrontational' (ie not argue), emit 
flattering-seeming responses, and then when we 
have all "agreed" in a nice comfortable-seeming 
consensus, it will emerge that I have agreed to 
do something I don't want to do (and you 
haven't.) I once worked in a building in which 
half the people there, one entire floor, did this 
to the other half, the engineers and researchers.

>Although i would generally recommend one or more 
>ontology engineering methods are adopted, even 
>only as guidelines,
>for a small ontology like person

Actually I think it might be quite large, eventually.

>your suggested approach may be enough
>
>I am a bit more rigorous when it comes to in 
>what sequence things are done, coming from a
>structured methods background, the task hierarchy may be important
>and I would argue that following good practice 
>we should try to first describe the person 
>properties and their relationship and naming 
>conventions, as well as discuss (discuss = plain 
>english) the various representation and 
>formalization options, before writing the 
>ontology in one or another language itself.

Here's the problem. Suppose we do this and agree 
on the properties and so on, all in English; and 
also agree on a formalism. Immediately, as soon 
as the properties and so on are written down in 
the formalism, they no longer mean what they 
meant in English, when we agreed on them. In some 
ways they mean less, of course; but in some other 
ways they mean more: their meanings are 'sharper' 
than those of English words, more exactly drawn. 
This is why single words in English (like 
"cover") have to be given many alternative 
meanings in formal ontologies (Cyc has something 
like 20 different sense of 'cover' all carefully 
distinguished.) So, it often turns out, the 
agreement that we so painfully constructed back 
in the English wasn't in fact an agreement at 
all, because some of us were thinking of one of 
the precise senses and others of another (and 
others still weren't even aware of the 
distinctions.) Often, at least in my experience, 
the ONLY effective way to even get the necessary 
distinctions clarified to the point where 
agreements or disagreements can begin to be be 
discussed, is to begin to formalize them. In 
fact, the formalization process consists in large 
part of clarifying and isolating shades and 
aspects of meaning that are never exposed in 
ordinary language discussions.

This, BTW, is why ontology engineering differs so 
markedly from software engineering. An early 
software specification might be impractical or 
impossible to implement, but it is usually 
reasonably clear as a description of the desired 
behavior. As the design process continues, the 
specification becomes more quantitatively 
precise, but at no stage is there much ambiguity 
about the meanings of the terms used. The big 
engineering decisions have to do with topics such 
as the overall structure of the software design, 
the large-scale strategic decisions (such as the 
Cisco decision to rely on forward inference and 
query access rather than a tableau method for 
their OWL reasoner). But when writing an 
ontology, there really isn't very much 
'large-scale' structure to worry about: there 
aren't any big strategic choices between rival 
methods, etc.. But there *are* worries about what 
the words used in the description *mean*. And an 
elaborate description couched in a language which 
we know is going to change as soon as we 
formalize it can't be anything more than a 
preliminary sketch.

>  And first, absolute first, must be requirements analysis
>as you and I already discussed and partly agreed 
>on the Ontolog list a while back

Well, true. I'd like to have a clearer idea of 
what this ontology is supposed to be used for. 
Perhaps the project leaders could oblige us ??

>Construct an ontology. It almost does not matter exactly where you
>start, but either the very top (most general) or the very bottom
>(data) is not usually a good place. If you don't know how to start,
>one way is to get a bunch of domain experts together in a room and
>have them idea-storm, e.g. by constructing a concept map together.
>(This needs someone to take notes.) However, Im not sure what a
>domain expert on the topic of people would be.
>
>
>we can easily  use  some free mind mapping 
>soffware and get the good people on this list
>to do that kind of brainstorming remotely, would that work for you?

Worth trying, but my experience is that working 
remotely isn't very effective. One needs a 
certain degree of the 'vatican council' effect 
where the people are all put in one room and 
mutually forced to focus on the topic, to get the 
group past the 'stuck' periods which inevitably 
happen. Also the process happens at a vastly 
higher rate when SMEs are talking together and 
one person is manipulating the keyboard.

>
>TQM is a QE  method. QE is a discipline in its 
>own right, albeit not too well known
>
>
>
>I once was obliged to take a training course in
>TQM, since when I have never been able to take anything with the word
>"quality" in it seriously. What is your definition of "quality" ?
>
>
>I assure you, its serious. You may argue that 
>ontology is not strictly software, but it is 
>also software, and the entire ontology 
>engineering lifecycle is equivalent to softwrae 
>engineering lifecycle in most established 
>methodologies

Well, there isn't (AFAIK) yet an accepted 
'ontology engineering lifecycle', but Im sure 
that if one ever gets stated then it won't be 
much like the software engineering lifecycle in 
anything but a very general, overall sense.

>  There are  ieee and ISO standard for quality in 
>software related products - I think 9042 or 
>something (dont have my notes here) Quality is 
>not just one thing

In the course I was obliged to take, quality was 
defined to be whatever made the customer happy. 
(I think that course was being given by 
incompetents, so I should not assume that the 
entire field is that daft. But it did leave me 
extremely sensitized to intellectual nonsense 
wearing the clothing of management theory.)

>, but the combination of many factors I can give 
>the full  set of lectures for those who are 
>intersted (one semester)!
>:-)

If they are on-line, I will undertake to read 
them all (eventually). (I approach things like 
this rather as a ethnographer approaches an alien 
culture, trying to understand it without actually 
joining it. What I find the most interesting 
question is, why do people take this seriously? I 
have never seen an empirical test which shows any 
of these theories to be more correct than any 
others.)

>
>from some generic web source
>Are you or Software QA involves the entire 
>software development PROCESS - monitoring and 
>improving the process, making sure that any 
>agreed-upon standards and procedures are followed

In other words, getting in the damn way and 
creating large amounts of non-work which subtract 
effort from the actual work.

>, and ensuring that problems are found and dealt 
>with. It is oriented to 'prevention'.
>
>search for quality assurance Nasa, I work with thoe guidelines (appropriately
>scaled down to fit the mission requirements) they take quality seriously
>
>anyone on this list going to be at Busan btw

Not me, sorry.

>
>Pat, see if you can punch out a plan based on the good suggestions above
>I'd love to see this happen

Aha! I KNEW I was being manipulated.  I don't 
know how to punch out plans. Come on, you are the 
manager type who knows about Quality. YOU punch 
out a plan :-)

Pat

>
>PDM
>
>
>  >
>>p
>>
>>On 10/26/07, Pat Hayes <<mailto:phayes at ihmc.us>phayes at ihmc.us> wrote:
>>>  >  >  I say that before encoding ontology, there is some groundwork to be
>>>  >>done in plain english.
>>>  >
>>>  >OK. What?
>>>  >
>>>  >
>>>  >write spec - (lots of subtasks there)
>>>
>>>  OK, perhaps then you can tell me what a spec of
>  >>  an ontology should look like. I have never seen
>>>  one.
>>>
>>>  >  OWL is not a programming code, and
>>>  >formalizing knowledge is not like programming.
>>>  >
>>>  >
>>>  >It's a 'metaphor'
>  >>
>>>  ? WHat is a metaphor for what here? YOu have lost
>>>  me. If you are using programming (esp. management
>>>  of large software projects) as a metaphor for how
>>>  to build ontologies, I thinkn you are using a bad
>>>  (= highly misleading) metaphor.
>>>
>>>  >  - but I think you and I do not share the same background, therefore
>>>  >you tend to misinterpret my constructs
>>>  >regularlty. I wish I could express myself using
>>>  >mathematical formulas
>>>
>>>  Well, I do read and write English reasonably proficiently.
>>>
>>>  >Listing relevant facts and topic areas, and
>>>  >first application areas, might be well worth trying, however.
>>>  >
>>>  >
>>>  >sounds like a good start -  diagrams are useful
>>>  >to some people, and not so useful to others
>>>  >but the fact that they are not useful to you,
>>>  >does not mean that you have the right to
>>>  >wipe them off the project
>>>
>>>  True, I don't think I have any authority to wipe
>>>  anything. However I do have the right to ignore
>>>  them and requests to draw them, which I shall do.
>>>
>>>  >  >
>>>  >>so, shall we start? (before worrying where it ends)
>>>  >
>>>  >Are there any facts about people that any of us are likely to *not* agree
>>>  on?
>>>  >
>>>  >
>>>  >I can answer that after you tell me what the
>>>  >facts are, Where are the 'assertions'
>>>  >of this ontology?
>>>
>>>  You have already said that you want to do all
>>>  this BEFORE any assertions have been written. The
>>>  assertions ARE the ontology.
>>>
>>>  >so that we can discuss them (apols if I they are
>>>  >somewhere that I have not seen, but ifs so, they
>>>  >should be pointed to when referring to them)
>>  > >
>>>  >
>>>  >  >also, did nt you say that somethin in Higgins is broken, maybe
>>>  >>that's something that should be worked on before thinking of coding
>>>  >
>>>  >It was the coding that was 'broken', but maybe 'highly idiosyncratic'
>>>  >would be a better description.
>>>  >
>>>  >
>>>  >I see, syntax then - was wondering about that
>>>
>>>  No, not syntax: semantics. HOWL is syntactically correct OWL.
>>>
>>>  Pat
>>>
>>>  >
>>>  >thanks
>>>  >
>>>  >PDM
>>>  >
>>>  >
>>>  >
>>>  >
>>>  >>
>>>  >>
>>>  >>Paola
>>>  >
>>>  >
>>>  >--
>>>  >---------------------------------------------------------------------
>>>  >IHMC            (850)434 8903 or (650)494 3973   home
>>>  >40 South Alcaniz St.    (850)202 4416   office
>>>  >Pensacola                       (850)202 4440   fax
>>>  >FL 32502                        (850)291 0667    cell
>>>  >phayesAT-SIGNihmc.us
>>>  ><<http://www.ihmc.us/users/phayes> 
>>>http://www.ihmc.us/users/phayes><http://www.ihmc.us/users/phayes>http://www.ihmc.us/users/phayes
>>>  >
>>>  >
>>>  >
>>>  >
>>>  >--
>>>  >Paola Di Maio
>>>  >School of IT
>>>  ><<http://www.mfu.ac.th>http://www.mfu.ac.th> 
>>><http://www.mfu.ac.th>www.mfu.ac.th
>>>  >*********************************************
>>>
>>>
>>>  --
>>>  ---------------------------------------------------------------------
>>>  IHMC                (850)434 8903 or (650)494 3973   home
>>>  40 South Alcaniz St.        (850)202 4416   office
>>>  Pensacola                   (850)202 4440   fax
>>>  FL 32502                    (850)291 0667    cell
>>>  phayesAT-SIGNihmc.us 
>>><http://www.ihmc.us/users/phayes>http://www.ihmc.us/users/phayes
>>>
>>>
>>
>>
>>--
>>Paola Di Maio
>>School of IT
>><http://www.mfu.ac.th>www.mfu.ac.th
>>*********************************************
>
>
>--
>---------------------------------------------------------------------
>IHMC            (850)434 8903 or (650)494 3973   home
>40 South Alcaniz St.    (850)202 4416   office
>Pensacola                       (850)202 4440   fax
>FL 32502                        (850)291 0667    cell
>phayesAT-SIGNihmc.us 
><http://www.ihmc.us/users/phayes>http://www.ihmc.us/users/phayes
>
>
>
>
>--
>Paola Di Maio
>School of IT
><http://www.mfu.ac.th>www.mfu.ac.th
>*********************************************


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes



More information about the Person-ontology mailing list