Difference between revisions of "Unscheduled Projects"

Revision as of 13:52, 6 February 2008

About

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

Ontology-related

Ontology description language

• We currently use OWL-FULL 1.0 in HOWL
• Now that we've got some experience with OWL we see its limitations
• Should we move to OWL 1.1 or to something else?

I-Card Selector UIs

• 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

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 I-Node Relations as first-class objects, IdAS in Higgins 1.0 treats them shallowly. For example, a search (e.g. using an IdAS Filter) treats I-Node 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

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 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

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

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