Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Higgins data model

I like it just how it is Jim.

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 3/29/2006 5:35:17 pm >>>
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


Back to the top