>
>>I agree that you can make the logical manoeuvres that you are suggesting,
>>but there is another question.
>>
>>How elegant is the solution?
>>Is the proposal just a hack?
>>And if it is, so what?
>
>Well, Im all in favor of hacks if they work, both
>in coding and in writing ontologies. More
>seriously, terms like 'just a hack' convey
>nothing useful, seems to me. The case I was
>arguing was that any ontological content CAN be
>expressed in FOL. Responses along the lines of
>"OK, but I don't like that way of expressing it'
>(which is what 'just a hack' means) are not
>persuasive.
>
>CP>At one level I really agree with you. I think the first hurdle to
>overcome is to get things working, and at that stage worrying about whether
>something is a hack is counter-productive. Once over that hurdle, I think
>different problems arise. As the system gets more complex, management
>concerns start to raise their ugly head.
>
>>
>>I had an intuition that this was an important question, but could not
>really
>>put my finger on a good argument until recently.
>>
>>Last year a colleague gave me a book on complexity theory that gave me the
>>beginnings of an argument.
>>
>>The book is - but the argument is good. I can send you
>>the relevant scanned pages if you want - be warned the pdf is enormous.
>
>Book reference and page #s will do.
>
>CP> MAKING THINGS WORK: Solving Complex Problems in a Complex World by
>Yaneer Bar-Yam, President New England Complex Systems Institute - pp 28-29,
>44-49, among others.
>
>>
>>Anyway, the nub of the argument is this.
>>
>>When the complexity (complexity theorists seem to call what IT people call
>>functionality, complexity) of a tool is not up the task, you need to use a
>>workaround. The greater the gap, the greater the number of workarounds.
>>
>>Now a lot of the work I do consists of trying to spot workarounds, and
>>guessing what aspects of the tool (for tool read ontological foundations)
>>need to be improved to make the tool sufficiently complex/functional. So
>>this seems to make sense.
>>
>>I also chatted to a few complexity (software) people and they all said they
>>could not understand traditional software architects all seemed to try to
>>build complexity (i.e. functionality) OUT of the system. This struck a
>>chord, as often the changes I was talking about (e.g. multiple rather than
>>single inheritance) were condemned by programmers as too complicated
>>(happened again last week). OK, I accept the foundation was a bit more
>>sophisticated, but it made the rest of the system much MUCH simpler. We get
>>order of magnitude reductions in code.
>
>Sounds like what you were calling an improvement is what they would call a
>hack, no? Are you sure you are talking about the same thing here?
>
>CP>Absolutely sure it is about the same thing. (01)
What I meant was, your ontological 'hack' (single inheritance) is
their good programming practice, and vice versa. Same idea, but a
hack at one level is elegant at a different level. (02)
...
>
>>
>>I accept that I cannot now easily define what a workaround is, but most
>>people can sense where there is one. My question really is whether this is
>>happening in some on the logical manoeuvres you are making. Not claiming to
>>always know the answer - just raising the question.
>
>Well, Im not sure what an ontology workaround
>would be like. The danger I can see is that
>anything at all complicated is condemned as a
>workaround or a hack, without saying what it is
>that one supposed to be working around exactly.
>Is making the distinction between a lake (same
>body of water from day to day even though every
>pint of water is replaced by river flow in about
>three days) and a particular 'piece' of water
>(which is dangerous to drink because
>contaminated, say) "just a hack", or is it a
>genuine ontological distinction? It sure *feels*
>like the latter.
>
>CP>I would say it is a genuine ontological distinction.
>
>CP> What I would see as a hack (and this was proposed to me this week) is
>that as O-O programming languages tend to support single inheritance, so
>subsumption/subtyping/subclassing should be single inheritance - i.e. a type
>should only have one parent. (03)
Aaargh. This just sounds plain wrong. (04)
>It is possible to code a system this way (I was
>showed an example), but it does take some ingenuity - and effort. (05)
Im amazed it is possible at all. (06)
>CP>Another example of a hack is suggested by Lakoff's Women, fire, etc.
>book. In the absence of any form of writing, it probably makes sense to put
>things into four categories - and women then get dumped in the same category
>as fire and dangerous things. However, now we have writing and computers,
>this seems a little primitive. (07)
Ive always understood that category as "Things which if left untended
can get out of control and become dangerous, so require ones unbroken
attention when present." Similar sentiments were expressed by a later
poet: "Hell hath no fury, like a woman scorn'd." (08)
>(This is a version of my pile argument form
>above.) Would you argue that this primitiveness, given our modern IT
>technology is just a subjective point of view.
>CP> Would you argue using just propositional logic or syllogisms when you
>have FOL is hacking - or common sense? (09)
Neither. I'd say if these will do your job for you, this could be
simple opportunism. (010)
Pat
--
---------------------------------------------------------------------
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 (011)
_________________________________________________________________
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 (012)
|