[higgins-dev] Unique Identification of Amalgamated Digital Subjects

["Tom Doman" <TDoman@xxxxxxxxxx>]

In perusing the Data Model, I was wondering about naming and\or unique
identification of Digital Subjects.  I went over the RDF Example One
(http://spwiki.editme.com/RDFExampleOne) and have some thoughts and
questions.

I realize the example is a simple one but, as usual, my thoughts are on
disparate joined systems.  We are expecting to deal with amalgamated or
crafted identities whose RDF properties may come from a variety of
sources and therefore, contexts.  The best practice and provision for a
"source" property is there and I like that, I think it's very necessary.
 However, the unique identifier in the example is listed as "unique to
the containing Context".  I realize there is always one top level
"momma" Context but that Context may only be an amalgamation of other
Contexts.  That is, it may not have a unique identifier it can call it's
own.  It could claim one as it's own and then try to "resolve" it when
referenced but that could get pretty messy.  That's the road we started
to analyze in the Bandit Identity Abstraction and I'm wondering if we
can avoid "resolve" issues by:

1. Specifying that the unique identifier must have a "source" provision
as well.
2. Specifying that a Digital Subject's unique identifier must also be a
sufficient "key" as to allow crafting of the same amalgamated identity
each time that identifier is referenced by the user of the top level
Context.  For example, it would be fine to use an LDAP fully
distinguished name with it's "source" as long as it could be used to,
say, look up it's GUID attribute which could then be used to find the
associated or "same" object in an SQL database to complete the crafting
of the identity.  The alternative would be to have the top level context
fabricate a unique identifier and keep a mapping table.  Sounds like a
virtual directory or something where there's an intermediate store for
persisting mappings ... doable but ugh!

Q1. I could see a case for saying a Digital Subject is NOT required to
specify a unique identifier if it is simply a set of other Digital
Subjects from various contexts all of which DO have a unique identifier.
 This would solve part of the complexity of #2.  However, the question
becomes, should this amalgamated Digital Subject be persistently
referenceable?  That is, the end user has something they can write down
("Paul Trevithick : Join Context 37" or "cn=pault,o=higgins : LDAP
Context 19" that can be sent to Join Context 37).  I believe it should
be persistently referenceable which brings us back to the full #2
above.

This then brought up the question,
Q2. Are we trying to present a unified namespace to the user of the top
level Context?  Context Providers which provide amalgamated identities
could emit unique identifiers with a variety of name forms for a given
set of Digital Subjects.  The wiki talks about the constituent players
of the US Tennis Team.  In a joined system, I may end up with Digital
Subjects which are uniquely identified in a variety of naming forms
(X.500, RFC822, GUID, Screen Name, etc.) for the constituency of that
team.  Ultimately, identifiers are presented to end users.  Which is
what brought me to Q2, again ... Are we trying to present a unified
namespace to the user of the top level Context?  Or are we saying,
that's how you configured your system, the identities are crafted ... at
least the identifiers are unique (that is, if we all agree on the other
stuff above).

It seems like all of this is within the domain of what we have to
specify in higgins or, at least, say we're not specifying and why. 
Thoughts?

Thanks,
Tom