Re: Contexts and views
tony@ontek.com (Anthony K. Sarris)
Message-id: <9506011502.AA01735@ontek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 1 Jun 1995 08:04:58 -0500
To: cg@cs.umn.edu
From: tony@ontek.com (Anthony K. Sarris)
Subject: Re: Contexts and views
Cc: macgregor@isi.edu, kr-advisory@isi.edu, srkb@isi.edu
Sender: owner-srkb@cs.umbc.edu
Precedence: bulk
Bob MacGregor wrote:
>In our system, its not possible to look inside of a context from
>outside. Instead, to "see" the facts, definitions, etc. in a context,
>you must be in it, or in one of its children. This is in accord
>with normal scoping rules.
I've been trying to follow this off-and-on context discussion, but may have
missed a note or two along the way, so please bear with me. If these
questions have all been dealt with already, simply e-mail me to let me know
that.
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)?
>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? For example, is the inheritance of all
properties/attributes optional or is an override at least provided? Is the
default to inherit the combination of all properties/attributes of all
parents, or to pick and choose from the various parents? Is there a way to
identify conflicting properties/attributes that might inherit from multiple
parents? Is the default approach to inherit the conflicting
properties/attributes and flag them in some way, or must the conflict be
resolved at inheritance? Must it be resolved by directly picking one from
among the alternative choices from the parents, or can a new 'hybrid' be
introduced?
>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?
In the case of lifting, does the lifted object assume its own identity in
the new context? 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. However, you
might at least want to know if/when the originating object changes (since
there might well still be some relationship between the lifted object and
its originating object in the old context), and then a human modeler would
have to decide whether or not to make the change or leave the lifted object
'as is' (which effectively cuts it off from its original source object).
Please don't take any of my questions out of context!
Cheers,
Tony Sarris "Beware of Geeks Bearing GIFs"
Ontek Corporation E-Mail: tony@ontek.com
22941 Mill Creek Drive Voice: +1.714.768.0301
Laguna Hills, CA, USA 92653 Fax: +1.714.768.0851