Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

HGraph

Revision as of 23:31, 14 June 2010 by Unnamed Poltroon (Talk)

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Higgins logo 76Wx100H.jpg

Motivation

The initial motivation for HGraph was to address a number of limitations of IdAS 1.1 related to describing and managing metadata.

Higgins-based applications have a requirement to be able to conveniently describe and manage metadata about regular entities. Examples include the need to cleanly separate provenance metadata entities from the base entities, or the need to be able to associate a set of attributes with a complex-valued (link-valued) attribute.

Imagine we have two contexts both of which make statements about entity e1. In the left-hand context, for which the RMV is the authority, we have the statement (e1 eye-color "blue") whereas in the right-hand context, for which the State Department is authoritative we have the statement (e1 eye-color "green"). These two authorities disagree about e1's eye color.

In IdAS this would be represented as follows:

Provenance 2.0.100.png

Where c1 and c2 are the entities that represent the contexts themselves.

IdAS 1.1 might be said to be context-centric. What we mean by this is that whereas the authoritative context for a given entityId (aka a UDI) can be discovered dynamically, there is no easy and fast way to assemble all of the other (non-authoritative) contexts that may also make statements about a given entity (of the same entityId). In practice this is sufficiently awkward that the general IdAS idiom is to simply not do so, and to only have a single context for information about an entity. In practice a given entityId typically only occurs in a single context--its authoritative context.

With this design the IdAS client code is responsive for keeping track of all of the contexts that contain a given entityId and essentially merging these representations together. Most of the client code will simply want to know the value of some attribute of e1 and doesn't care which context made the statement. In this case the code would want to know the value(s) of eye-color of e1. It simply wants the answer "blue" and "green".

To have acceptable performance the client code would have to maintain a list of all of the contexts that make statements about e1.


...to be continued

Back to the top