RE: [higgins-dev] Unique Identification of Amalgamated Digital Subjects

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Tom wrote:

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

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

Since the "source" for the unique identifier could be optional, adding it to
the data model doesn't burden developers in any way. So your #1 and #2 above
make sense to me.

> 
> This then brought up the question,
> Q2. Are we trying to present a unified namespace to the user of the top
> level Context?  

We have agreed that there is at least one "unified" namespace of identifiers
within a Context, namely, the CUID (contextually unique identifier
namespace) that we've been talking about here. There may, however, be other
identifier namespaces managed by a single Context as well. 

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

As I mention above, in a single joined context there may be multiple
identifier namespaces (what you call naming forms). We only require that one
of these be the CUID namespace. The other identifiers for the same Digital
Subject may or may not also be uniquely identifying.

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