Re: Contexts and views

macgregor@isi.edu (Robert MacGregor)
X-Sender: macgreg@quark.isi.edu
Message-id: <abf3f9730102100428c9@[128.9.208.151]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 1 Jun 1995 15:39:53 -0800
To: tony@ontek.com (Anthony K. Sarris), cg@cs.umn.edu
From: macgregor@isi.edu (Robert MacGregor)
Subject: Re: Contexts and views
Cc: macgregor@isi.edu, kr-advisory@isi.edu, srkb@isi.edu
Sender: owner-srkb@cs.umbc.edu
Precedence: bulk

At 05:04 6/1/95, Anthony K. Sarris wrote:
>Bob MacGregor wrote:
>>In our system, its not possible to look inside of a context from
>>outside.>I understand the last two sentences of Bob's note above, but I'm
>>not sure
>I'm entirely clear on the first sentence. Bob (or anyone else who knows
>about this), does this mean that in your system when you are 'in' a given
>context, all other [foreign] contexts appear as only labels or references
>or whatever, and that to view them you then 'open' that context separately.
>Is this more of a visualization point or primarily a logical one indicating
>that what is within one context has no real meaning or standing in any
>other context, so don't try to mix the objects from different contexts
>unless you do so formally (by lifting or inheritance)?

In an executing (Loom) program, you are always "in" the current
context (just like in Lisp you are "in" the current package).  Unlike,
Lisp packages, you can change the current context anytime you like.
For example, you can dynamically create (fork) a child context, and
then move into it.  Symbol table references are evaluated relative
to the current context.  A reference to "foo" is resolved by looking,
in the current context, and then recursively up the parent chain
until you find "foo".  Shadowing (of foo) is frowned upon, but its
possible (I won't go into that unless pushed).

>
>>Also, we support
>>multiple inheritance -- our context hierarchies are not limited
>>to trees.  We have quite a few users (mostly in the NL domain)
>>who use the multiple inheritance feature.  One way to reason
>>with two different views/contexts is to create a new context
>>that inherits both of them.
>
>Does this work pretty much like multiple inheritance in many
>object-oriented paradigms?
Not really; your description sounds like property inheritance.  Here,
we are inheriting facts from all parent worlds, recursively.
A child context is permitted to cancel (retract) an inherited
fact, i.e., inheritance is not required to be monotonic.

We have a two possible semantics for resolving the inheritance of conflicting
facts.  One possible resolution is to mark a context that inherits
conflicting facts as inconsistent, meaning that its up to the
user to resolve the conflict (by making local cancellations of
the offending facts).

>
>>We have also identified (but not yet implemented) a need for
>>an export feature (lifting).  Often, one would like to reference some
>>of the objects in a context without inheriting that context.
>>That provides a second means for interviewing the contents
>>of a context without being in or below it.
>
>In 'lifting', is the lifted object placed directly in the new context,
>versus merely establishing a reference (link), as in the second case above?
Logically, a copy of the lifted object is placed in the target context.
Otherwise, it would not be possible to update the imported object.
Whether or not to copy the attributes of the object is an open issue.
Physically, we do something more clever than copying the object (but
that's irrelevant here).

>In the case of lifting, does the lifted object assume its own identity in
>the new context?
No.  It important to recognize the object as being the same in both
contexts.

>Would it automatically change if the source object from
>which it was lifted were to change? This last point I find interesting
>because the second you place the lifted object in this new context, it
>becomes a part of THAT context and seems to take on a life of its own, so
>it would seem you might not want automatic change propagation.
Good question.  I can imagine arguments for both points of view
(you get hot links if the changes propagate).  A semantics that would
fit well with our implementation would be the following:  Changes
to an attribute of the lifted object made in the source context would
be visible in the target context UNLESS a modification had occurred
to that attribute in the target context.

Now you know why we aren't rushing to build the lifting facility.

Cheers, Bob


Robert M. MacGregor                                     macgregor@isi.edu
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292      (310) 822-1511