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.
Difference between revisions of "HGraph"
(New page: {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} right ==Motivation== The initial motivation for HGraph was to address a number of limit...) |
|||
| Line 5: | Line 5: | ||
The initial motivation for HGraph was to address a number of limitations of IdAS 1.1. | The initial motivation for HGraph was to address a number of limitations of IdAS 1.1. | ||
| − | Higgins-based | + | 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. |
| + | |||
| + | ...TODO show an example | ||
This is currently quite awkward to achieve with IdAS 1.1. IdAS 1.1 can be thought of as context-centric. 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. | This is currently quite awkward to achieve with IdAS 1.1. IdAS 1.1 can be thought of as context-centric. 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. | ||
| + | |||
| + | ...TODO show how the above example can be described in IdAS 1.1 | ||
...to be continued | ...to be continued | ||
Revision as of 19:10, 14 June 2010
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Motivation
The initial motivation for HGraph was to address a number of limitations of IdAS 1.1.
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.
...TODO show an example
This is currently quite awkward to achieve with IdAS 1.1. IdAS 1.1 can be thought of as context-centric. 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.
...TODO show how the above example can be described in IdAS 1.1
...to be continued