Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!pacbell.com!tandem!netcom!rodent From: rodent@netcom.COM (Ben Discoe) Newsgroups: comp.object Subject: Re: Has anyone taken an approach like this? Message-ID: <1991Mar21.171559.4916@netcom.COM> Date: 21 Mar 91 17:15:59 GMT References: <1991Mar19.042444.20834@netcom.COM> Distribution: comp Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 116 cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >>>>>> On 19 Mar 91 04:24:44 GMT, rodent@netcom.COM (Ben Discoe) said: >Ben> [...] is there a way to represent objects and the relationship >Ben> between then in a fashion that isn't redundant or brute force? I think >Ben> there is, but I'm having some trouble implementing it. >I understand "redundant", but what do you mean by "brute force"? By brute force I mean doing a sequential search through a long list of classes looking for some characteristic, versus organizing the structure of your class relationships so as to make conceptually related classes reachable to each other by means of a pointer or Class ID. Many people feel that redundancy or brute-force are the only options, but what I'm trying to develop is a representation that minimizes both. >Ben> I'd rather store the relationship once: >Ben> Dog "A eats B" relations Bird >Ben> ---- -------------------- ---- >Ben> eats -> DogOID/BirdOID <- eaten by >Ben> This way we can query "What does the Dog eat" and "What eats the bird" >Ben> and the searches can be non-brute force: we just follow the link to the >Ben> relationship, which contains the ID of the two involved objects. >In generalizing the problem this way, it would be better to express the >relationship as "Eater object" A "eats" "Eatable object" B with all the >derivations involved there. Depending on what you mean by "there", that's the approach I'm talking about, except: > The relationship then becomes a "hub" of >interaction between a number of different types of objects (all of which are a >KindOf Eater or Eatable types). Since Dog and Bird are already classes, how can they also be Eater and Eatable types unless you have multiple inheritance? I consider "Type" and "Class" interchangeable. This kind of typing I find far from intuitive... We don't think of "being eatable" as a property of a Bird, we think of "eating" as being an aspect of the relationship between the Bird and some carnivore. >Ben> Can generality also be represented this way? We can say "The Dog eats >Ben> meat." which will form a "A eats B" relation between the dog and an >Ben> aspect of the Animal class, a superclass of Bird. Then when we query >Ben> what eats the bird, we can search upwards through the class heirarchy for >Ben> any "eaten by" relations. These relations may be dependent on the value >Ben> of a class field, in which case we check to see if the object in question >Ben> (the bird) has the appropriate value for the realtionship to apply to it. > [...] However (as you also said), going the other >way is much more expensive because of having to scan a (potentially large) >number of different types of objects to find out what an ID identifies. If you mean locating an object once you have its ID, that's an implementation problem with all kinds of solutions. It's not a conceptual problem. The brute force that I'm trying to avoid is having to do potentially large scans of the Class and Relationship lists. >Ben> Now, how do we represent this in the relations list? >Do you need to do anything more than represent in the relations list the >generalized IDs of the objects participating in the relationship? That is, >the IDs in the relationship are of type EaterID or EatableID. Yes, there more! Most relationships (both in our minds and in "the real world") are conditional. To make a lousy example, say "Dog eats Bird objects which are blue and >1 year old". The challenge is to encode the conditions such that the bidirectional nature of the links is maintained, so that we never do brute-force scanning. The way to model this that come to my mind is to require that color and age are aspects of the Bird class, then, under the Bird class, have a link to the relationship that encodes "only if condition1(age) and condition2(color)" The relationship object, will have to have a link not only to the Bird object but also point to the specific link inside the Class. (All links should bidirectionally point at each other so that query algorithms can traverse the trees and logical constructs we simply following pointers!) >Ben> 2. Are there any obvious drawbacks? >Especially in the generalized sense, there is a strict typing problem to worry >about. That is, taken very far, this approach will lead to massive typing >trees with some connections that are very difficult to represent (how do you >represent the ID of something that can both Eat and be Eaten?). This isn't a problem if you abandon the idea that, for instance, all eatable objects are subtypes of Eatable type. See above for why this isn't intuitive or desireable. >Ben> Why can't I find >Ben> anyone else pursuing it? I've scanned all the papers and conference >Ben> proceedings I can get my hands on. >Probably because of the massiveness of the typing problem. Either I don't understand what you mean by this problem, or its not real? Since my original post I've received helpful replies pointing that indeed, many people ARE working on "my" approach. I am now more confident that there are no severe inherent difficulties... > This seems more >readily doable in a relational system because relationships are derivable >directly from the data rather than definition of the data. Is this a drawback >to the object-oriented model that doesn't bother the relational model? I don't see any drawback to the OO representation of Classes/Relationships (assuming my current concerns are ultimately solvable, an open question) and I see all kinds of problems with the classical relational model (I work for a company that makes a "relational" database). It seems that those shortcomings are what attract many people to OODBMSs. >David Masterson Consilium, Inc. --------------- Ben in San Jose. Can I contribute to the (OODB?) world without becoming a specialist?