| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Nicola Guarino writes: > > At 5:43 PM +0200 8/6/2000, Markus Pilzecker wrote: > >Nicola Guarino writes: ... > >With focus on a single entity, you never have > >[technical] problems to inherit one feature after the other, while walking > >down the inheritance tree. Order doesn't matter. The interesting point for > >multiple inheritence comes in, when you want to raise reusability of your > >model parts by making them freely combinable. Near to your example, if you > >have concepts of ``window'', ``brick'' and ``concrete_wall'', a client may > >combine some of them to construct concepts like > > brick_building=(brick+) > > brick_window_building=(brick+,window+) > > concrete_wall_building=(concrete_wall+) > > concrete_wall_window_building=(concrete_wall+,window+) > > brick_concrete_wall_window_building=(brick+,concrete_wall+,window+) > >... > > I am not sure I understand this example. I meant this:
buildingology.classdiagram.gif
> What does the plus sign mean? Cardinality is arbitrary positive. > Intuitively, however, if a "concrete-wall-window-building" is > intended to be both a "concrete-wall" and a "window", it may be > important to observe that there is a common interpretation of > "concrete-wall" such that you can't see through it, while exactly the > contrary holds for "window". Sorry, that I didn't have been more precise in my first posting. As you can see now, I understood a concrete-wall-window-building to be a building, which has [at least one] concrete_walls and [at least one] windows. > At least under this interpretation, this > example of multiple inheritance is inconsistent. I just wanted to > point out that many examples of multiple inheritance appearing in > well-known ontologies risk to be inconsistent as well. > So, as having been pointed out in other postings as well, it is desirable to search for an answer to the question, if an automatic consistency check is achievable in principle. Oh, yes: what _is_ consistency?? Single inheritance has another draw-back: you have to make arbitrary decisions, in which order to inherit orthogonal features. And if the model is to be extended in order to combine other features, the already existing concepts /*alias classes, ...*/ could not be reused without introducing redundancy [, which is hard to maintain in the future]. ... > > The ontological status of shapes is a different issue (which I am > happy to discuss under a different subject line). For the sake of my > argument, the only point is that castles have certain "essential" > properties that bunches of bricks don't have. > Of course. A castle is generally considered not only to be a ``bunch of bricks''. Bye, Markus