Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.object Subject: Re: Has anyone taken an approach like this? Message-ID: Date: 20 Mar 91 19:52:30 GMT References: <1991Mar19.042444.20834@netcom.COM> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California Lines: 87 In-reply-to: rodent@netcom.COM's message of 19 Mar 91 04:24:44 GMT >>>>> On 19 Mar 91 04:24:44 GMT, rodent@netcom.COM (Ben Discoe) said: Ben> I've been thinking heavily about an approach to object-oriented databases Ben> that mixes in elements of hypertext, knowledge-representation, etc. It's Ben> basis is this: 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"? Ben> Rather than store every relationship twice: Ben> (The following Capitalized words represent CLASSES, not instances) Ben> Dog Bird Ben> ---- ---- Ben> eats Bird is eaten by Dog Ben> I'd rather store the relationship once: Ben> Dog "A eats B" relations Bird Ben> ---- -------------------- ---- Ben> eats -> DogOID/BirdOID <- eaten by From an object-oriented view, the obvious problem here is that the relationship now becomes an object by itself rather than a property of either Dog or Bird (or both). Since anything can be an object, this may not be wrong, but it is a difference in the basic philosophy of the problem as expressed in the first representation. 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. 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). 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. As you said, finding whether an object is used in a relationship (as in "The Dog eats") is relatively easy in the general case (get the ID of Dog and see if ID is in relationship list). 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. This kind of goes with the "asking an object its type" thread that's been raging in comp.lang.c++. 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. Ben> I'd be interested to know: 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?). Ben> 3. This method seems appropriate for modeling anything from an Ben> encyclopedia to a rainforest to a coin collection. 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. 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? -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"