Preliminary Data Model Goals

Higgins context providers transform data from underlying data sources into a canonical Higgins data model. These context providers map data from these kinds of places:

1. Directories: LDAP stores like eDirectory, Active Directory, OpenLDAP, etc...
2. Relational databases used by enterprise apps to store identity/profile information.
3. Digital social networks (node-edge graphs): data behind LinkedIn, Friendster, etc; or the graphs created by mining email traffic
4. Email/IM/collaboration client account data: email and IM client accounts, contact/buddy lists
5. Identity/profile data stored in website "silos": personal information stored sites like eBay, Amazon, Google Groups, Yahoo Groups

Goals for the core data model

1. Multiple Contexts. Supports any number of separate contexts. Each context acts as a namespace for a set of identifiers that uniquely identify objects called "DigitalSubjects" within the context. (DigitalSubjects are currently called Members in Higgins 0.2)
2. Context Relationships. Contexts have objects called ContextRelationships that support associations with other Contexts.
3. ContextRelationships are 1:1 or 1:M
4. DigitalSubjects have type. DigitalSubjects have an explicit attribute that defines their type.
5. DigitalSubjects have attributes.
6. Attributes are typed by what are called their "names". Attributes names indicate the type of the attribute. They are user-defined and easy to ensure are unique across applications.
7. Attribute values can be literals or compound objects with arbitrary "properties".
8. Attributes have Sources. A Source is a reference to a DigitalSubject (usually resolvable to an DigitalSubject in another more "meta" context). <note: this goal has been generalized and subsumed by saying that Attributes (among other things) may have associated "metadata">
9. DigitalSubject Relationships. DigitalSubjects can be associated with other DigitalSubjects via what I'll call here "DigitalSubjectRelationship" instances.(Relationships are called Edges in Higgins 0.2)
10. SubjectRelationships are typed.
11. SubjectRelationships have arbitrary metadata.
12. SubjectRelationships are 1:1 or 1:M
13. Addressing. DigitalSubjects, and their associated attributes can be addressed using a simple, consistent indexing/navigation scheme. This scheme must support navigation via SubjectRelationships to other DigitalSubjects as well as to the attributes of the DigitalSubjectRelationship object itself.
14. NEW: <need to add something here about the need to have an extra level of indirection in how DigitalSubjects are referenced (in SubjectRelationships) and Contexts are referenced (in ContextRelationships) in order to allow durable references while allowing the network endpoints (e.g. URLs) to which they resolve by dynamically mapped. This is the main argument for using XRIs. We want to allow relationships between DigitalSubjects and between Contexts to be durable, while allowing, for example, the data provider (as exposed through a context provider) to be switched underneath. This "lock-in" prevention is a key design goal of Higgins). >

Other goals

1. Fully qualified data. The ability to fully qualify all data on a DigitalSubject (including it's relationships and attributes) is needed from a management perspective. In other words, if I see that John has a department phone number, I (or the context provider) will need to know that it was fabricated by following John's administrative assistant relationship to another DigitalSubject and using the phone number there (if that's what happened). This is so I (or the context provider) can know how to update it.

Support for operations

1. DigitalSubject Joining. The ability to "join" identities from different sources (create on "John" from stuff in an SQL DB as well as an LDAP store).
2. Multilevel context provider support. Support an architecture where context providers can present data in this model by consuming and transforming data from either (a) physical data sources or (b)context providers operating "one level down"