|
|
| Line 2: |
Line 2: |
| | This page is a collection bin for projects that might be addressed in future releases of Higgins. | | This page is a collection bin for projects that might be addressed in future releases of Higgins. |
| | | | |
| − | == Community ==
| |
| | | | |
| − | === Evangelism ===
| |
| − | * The Higgins project has done very little outreach to attract other developers.
| |
| − | * Should we have a campaign to reach out more?
| |
| | | | |
| − | === Liaisons ===
| |
| − | Need more liaison/dialog with:
| |
| − | * http://fstc.org
| |
| − | * ...lots more
| |
| | | | |
| − | == Data Model ==
| |
| | | | |
| − | == Internationalization of Higgins ==
| |
| − | * Leverage the Babel project: http://babel.eclipse.org/babel/
| |
| | | | |
| | | | |
| − | == I-Card Selector User Interface Harmnonization ==
| |
| − | * Higgins is blessed(!) with multiple i-card selector UIs (DigitalMe Linux, DigitalMe OSx, Eclipse-based, web-based-Firefox(in-browser), web-based-IE)
| |
| − | * Need to reduce the number of parallel implementations
| |
| − | * Need to converge on a common UI
| |
| − | * Need to improve the UI
| |
| | | | |
| − | == Higgins on Mobile Devices ==
| |
| − | * Contributions of Android prototypes
| |
| − |
| |
| − | == New Candidate Layers over the IdAS API ==
| |
| − | This section describes several sets of functionality that could be layered over the current IdAS API.
| |
| − |
| |
| − | === XDI 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 [[Node 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 [[Node 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
| |
| − |
| |
| − | ==== Examples of new (deep) search functions ====
| |
| − | Given DS A in context C find all other DSes with relationships to A. Parameters:
| |
| − | * [optional] min threshold of relationship level
| |
| − | * [optional] within context C or across "all" Contexts (whatever all means!)
| |
| − | * [optional] max of N degrees of separation (hops)
| |
| − | * [optional] sort by relationship/context or context/relationship
| |
| − |
| |
| − | Given DS A in context C find other contexts Cn where Cn != C such that C contains DSes with a relationship to A
| |
| − |
| |
| − | Given a DS A in context C return the union of all all attributes (and their values) of A by following all correlation links from A Parameters:
| |
| − | * [optional] max of N degrees of separation (hops)
| |
| − |
| |
| − | === 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 ===
| |
| − | 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
| |
| − |
| |
| − | == Emergent Contexts ==
| |
| − | Dynamically generate a new context and populate it with DSes correlated to their corresponding "base" DS such that the base DSes (in whatever context) share a set of attribute types (e.g. zipcode).
| |
| − |
| |
| − | Dynamically generate a non-empty context by automatic clustering (any facet, any property, any context)
| |
| − |
| |
| − | == Identity Selector Selector ==
| |
| − | ''Requirements''
| |
| − | # Allow user on any platform to configure what selector they would like to be their default
| |
| − | # Consistent UX on all platforms for setting/changing the default
| |
| − | # Consistent API from browsers and local apps
| |
| − | # Decouple browser <object> tag parsing from selector
| |
| | | | |
| | == Selector Platform Requirements == | | == Selector Platform Requirements == |
| | * [[Selector Platform Requirements]] | | * [[Selector Platform Requirements]] |
This page is a collection bin for projects that might be addressed in future releases of Higgins.
