| RE: [higgins-dev] Higgins data model |
|
All,
Here's the mail I plan to send to Vincent later tonight - maybe after shortening it a bit. Let me know if it's off base or needs work...
--
Thanks Vincent,
Ok, so in broad strokes, The Higgins project (if you read here: http://spwiki.editme.com/Higgins) seeks to provide a framework for integrating identities (now called DigitalSubjects). A DigitalSubject is really just a representation of something (like a person, a computer, a deed of trust, whatever). Everyone agrees that an DigitalSubject has an identifier and a set of attributes.
Higgins defines something called a Context. A context is basically a container of DigitalSubjects. The thought is that a DigitalSubject makes sense from the perspective of its containing Context. For example: I might have a buddy list context which contains all my friend's IM DigitalSubjects. There may be a Novell Context which contains all the employees of Novell. So in once sense, a Higgins Context is somewhat analogous to an instance of a specific namespace. To go further, a Context may consume other Contexts and re-present DigitalSubjects as being joined together (i.e. I could have some uber Context which joins data from an LDAP directory and an SQL database to make it appear as if the DigitalSubjects are all held within my uber Context.)
DigitalSubjects within a context will have a unique identifier - likely a URI or XRI.
DigitalSubjects will also have a set of attributes. There is also the desire to draw relationships between DigitalSubjects. For example, one DigitalSubject might have a parent/child relationship with other DigitalSubjects, and might have a management relationship with others. A single-dimensioned hierarchy (like the X.500 user data model) is insufficient to model all the different relationships needed.
Let's see, what else...
The goals here (http://spwiki.editme.com/DataModelGoalsM4) are still in flux, but do represent generally what people are looking for. And this page (http://spwiki.editme.com/DataModelProposal) has a rough outline of a current proposed data model.
We began work at Novell a few months ago on something very similar (Identity Abstraction at bandit-project.org), and just started using JNDI as the interface. We did that for two main reasons: 1) we saw JNDI as being a close enough fit for what we needed, and 2) JNDI has been around for a long time, people are used to it.
In our model, the consumer would be presented with a fairly flat namespace where the DigitalSubject is always a leaf (we had the notion of a flat space of Contexts (we called them Realms), and below that, a flat namespace of DigitalSubjects. In our model using JNDI, any relationship to other DigitalSubjects would probably be done using attributes (the same way directories associate a group object with its members). We didn't have the notion of Contexts being related to Contexts (Realms to Realms in our terms).
Since then, we've become aware of Higgins and due to the close match in goals, we want to collaborate there. The Higgins model has its roots somewhat in the RDF/Semantic world, and thus is a bit different from where we were going. We want to do analysis into both models to make sure we're considering all the pros/cons of the different models.
So I think the types of questions we have in terms of JNDI come in two flavors:
1) Can JNDI be used to meet the Higgins goals?
2) Has JNDI been proven to be too "X.500/LDAP" ish to map well on top of various data stores?
I know that answering questions of the #1 flavor will probably be hard without a more details (or more pointed questions). I didn't want to flood this first email with too many specific questions, so maybe you'll have some questions back in this area.
I'm hoping you have some experience or background knowledge on #2, where you could show examples of good and/or bad fits.
Thanks for agreeing to help out with this,
Jim |