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

Difference between revisions of "Beyond Higgins 1.0"

(Caching and Indexing)
(Candidate layers above current IdAS API)
Line 8: Line 8:
 
=== Web service endpoint===
 
=== Web service endpoint===
 
As discussed in the previous Austin F2F in October 2007, the Higgins project has decided that an IdAS web service is in scope for the future of Higgins. Parity will be developing and contributing an XDI endpoint.
 
As discussed in the previous Austin F2F in October 2007, the Higgins project has decided that an IdAS web service is in scope for the future of Higgins. Parity will be developing and contributing an XDI endpoint.
 
+
* Can only be implemented as a layer over IdAS, not as a Context Provider
=== Caching and Indexing ===
+
To enhance the performance of IdAS in situations where the underlying [[Context Provider]]s do not support caching and indexing on their own, and especially those that maintain connections to remote data sources, an generic caching/indexing layer could be useful.
+
  
 
=== Deep Search and Access ===
 
=== Deep Search and Access ===
 
Although the Higgins data model supports [[Subject Relation]]s as first-class objects, IdAS in Higgins 1.0 treats them shallowly. For example, a search (e.g. using an IdAS Filter) treats [[Subject Relation]]s no differently from other attributes. Many use-cases (esp. cross-contextual use cases) would expect that these links would be recursively traversed to N levels, with cycle detection, etc. and the attributes merged roughly analogous to inheritance.
 
Although the Higgins data model supports [[Subject Relation]]s as first-class objects, IdAS in Higgins 1.0 treats them shallowly. For example, a search (e.g. using an IdAS Filter) treats [[Subject Relation]]s no differently from other attributes. Many use-cases (esp. cross-contextual use cases) would expect that these links would be recursively traversed to N levels, with cycle detection, etc. and the attributes merged roughly analogous to inheritance.
 +
* Can only be implemented as a layer over IdAS
 +
 +
=== Caching and Indexing ===
 +
To enhance the performance of IdAS in situations where the underlying [[Context Provider]]s do not support caching and indexing on their own, and especially those that maintain connections to remote data sources, an generic caching/indexing layer could be useful.
 +
* Could be implemented either as a layer over IdAS or as a Context Provider
  
 
=== Schema(ontology) mapping ===
 
=== Schema(ontology) mapping ===
 
A layer that maps from each source ontology to a specified target ontology. This layer could consume the existing IdAS API and support the this same API --performing the mapping as the value add between the two.  
 
A layer that maps from each source ontology to a specified target ontology. This layer could consume the existing IdAS API and support the this same API --performing the mapping as the value add between the two.  
 +
* Could be implemented either as a layer over IdAS or as a Context Provider
  
 
=== Authorization ===
 
=== Authorization ===
 
A layer that acts as an authorization policy (e.g. XACML) enforcement point.
 
A layer that acts as an authorization policy (e.g. XACML) enforcement point.
 +
* Could be implemented either as a layer over IdAS or as a Context Provider
  
 
== Identity Selector Selector ==
 
== Identity Selector Selector ==

Revision as of 15:39, 6 November 2007

This is a new page to for Higgins concepts that will be addressed beyond the initial release 1.0.

Note: we're just getting started filling in this page. The upcoming Jan 8-10 Provo F2F Agenda will be the first place where we start the design work and discussions around these topics.

Candidate layers above current IdAS API

This section describes several sets of functionality that could be layered over the current IdAS API.

Web service endpoint

As discussed in the previous Austin F2F in October 2007, the Higgins project has decided that an IdAS web service is in scope for the future of Higgins. Parity will be developing and contributing an XDI endpoint.

  • Can only be implemented as a layer over IdAS, not as a Context Provider

Deep Search and Access

Although the Higgins data model supports Subject Relations as first-class objects, IdAS in Higgins 1.0 treats them shallowly. For example, a search (e.g. using an IdAS Filter) treats Subject Relations no differently from other attributes. Many use-cases (esp. cross-contextual use cases) would expect that these links would be recursively traversed to N levels, with cycle detection, etc. and the attributes merged roughly analogous to inheritance.

  • Can only be implemented as a layer over IdAS

Caching and Indexing

To enhance the performance of IdAS in situations where the underlying Context Providers do not support caching and indexing on their own, and especially those that maintain connections to remote data sources, an generic caching/indexing layer could be useful.

  • Could be implemented either as a layer over IdAS or as a Context Provider

Schema(ontology) mapping

A layer that maps from each source ontology to a specified target ontology. This layer could consume the existing IdAS API and support the this same API --performing the mapping as the value add between the two.

  • Could be implemented either as a layer over IdAS or as a Context Provider

Authorization

A layer that acts as an authorization policy (e.g. XACML) enforcement point.

  • Could be implemented either as a layer over IdAS or as a Context Provider

Identity Selector Selector

Requirements

  1. Allow user on any platform to configure what selector they would like to be their default
  2. Consistent UX on all platforms for setting/changing the default
  3. Consistent API from browsers and local apps
  4. Decouple browser <object> tag parsing from selector

See Also

Links

Back to the top