contexts
Contexts in this sense are environmental compartments, except they have the added capability to keep lists of origins.
Edelen and Ingwersen et al 2017: "Recommendations: ...setting an exclusive or inclusive nomenclature for flow context information that includes directionality and environmental compartment information."
In the antelope architecture, there are two different objectives for handling contexts as-presented by the data source.
In the default case, for every static resource or stand-alone archive a "TermManager" is created which is captive to the archive. The role of this class is to collect information from the data source in as close to its native presentation as possible. This creates an "inclusive" nomenclature for the source.
In the Catalog case, catalog's local quantity DB is an LciaEngine, which is also shared among all foreground resources. In this case the objective is to match a given context to the existing (exclusive) nomenclature built-in to the LciaEngine, so that contexts are guaranteed to coincide during LCIA.
In order to accomplish this, the native add_context() method needs to be expansive, fault tolerant, and widely accepting of diverse inputs, whereas find_matching_context() needs to be more discerning and rigorous. Thus the former accepts a tuple of string terms or a context, but the latter requires a context. find_matching_context searches first bottom-up then top-down to look for matches. It requires an input context to have an origin already specified, so that the resources can assign "hints" that map local terms to canonical contexts on an origin-specific basis.
Note that a "matching" generally requires an exact (case-insensitive) match to an entry in the contexts database. Curation of the synonym set is required.
Because contexts must be directional, some terms are protected as ambiguous: "air", "water", and "ground" should be avoided in favor of explicit "from air" or "to air" or synonyms.
The NullContext is a singleton defined in this file that is meant to imply no specific context. It is interpreted in two different ways: - on the characterization side, NullContext indicates the characterization has no specific context, and thus applies to all contexts, as long as a more applicable characterization is not found. - on the query side, NullContext indicates that a context was specified but no match was found. Queries with NullContext should not match any existing characterizations (except NullContext itself).
The NullContext should be returned by the context manager
Context
Bases: Compartment
If 'resources' or 'emissions' match any terms in a compartment, it is considered 'elementary', along with all its subcompartments.
A context has a natural directional "sense", which is either 'Source', 'Sink', or None. A Source context generates flows which may be inputs to the activity; a Sink context absorbs flows which are output from the activity.
If a context has a parent, it inherits the sense of the parent- specifying the opposite sense will raise an error.
elementary
property
A context's "elementary-ness" is determined by the top-most parent. Everything inherits from above. If the (lower cased) parent context is found in ELEMENTARY, it's elementary.
The only way to make a context elementary is to name it such, or give it an elementary parent.
Returns:
| Type | Description |
|---|---|
|
|
validate()
staticmethod
Need this for termination checking
Returns:
| Type | Description |
|---|---|
|
|
ContextManager
Bases: CompartmentManager
add_context_hint(origin, term, canonical)
Method for linking foreign context names to canonical contexts
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
origin |
origin of foreign context |
required | |
term |
foreign context name |
required | |
canonical |
recognized synonym for canonical context that should match the foreign one |
required |
Returns:
| Type | Description |
|---|---|
|
|
find_matching_context(context)
A complicated function to both (1) retrieve the best / most-specific "canonical" context for a given "foreign" (i.e. incoming) context and also (2) add the full semantic content of the foreign context to the canonical context manager.
(1) is accomplished by a heuristic both-first search, first looking at the foreign context from most-specific to least-specific and trying to find a match. if no match is found, we go back from least-to-most specific, using a slightly broader set of possible matches including heuristic names derived from contextual senses. If no match at all is found, then NullContext is returned -- the foreign context matches no canonical context.
(2) If a canonical context is found, then all non-matching contexts from least-specific to most-specific, are mapped onto existing sub-contexts of the match, or if none is found, collapsed into the match.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
context |
|
required |
Returns:
| Type | Description |
|---|---|
|
|
FrozenElementary
Bases: Exception
top-level elementary contexts may not be assigned non-elementary parents
ImmutableContextName
Bases: Exception
A context's hash comes from its name and thus the name may not be changed.
ProtectedTerm
Bases: Exception
currently triggered by the stale contexts file-- leading to an error in which "emissions;to water;low population density, long-term" and "emissions;to air;low population density, long-term" are synonyms in basic TermManagers. Should not present problems in LciaEngines, but the specific case is not tested.
Solution is to patch the local-contexts.json file to exclude this redundant term for water. Justification: the canonical contexts should be well-behaved and not contain any inherent conflicts. It is a nomenclature problem for the two contexts to have the same name.