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

["Tom Doman" <TDoman@xxxxxxxxxx>]

Ok, so given we're in agreement to add #1 to the data model.  I've been
discussing #2 with Jim and we've discussed making the unique identifier
open ended.  So, the top level context could simply join together all of
the unique identifiers from the sub-contexts it used to synthesize (just
adding yet another word to poke at jim ... joined, crafted, amalgamated,
what else can I come up with? ;)) the Digital Subject.  We'll have to
allow for arbitrary nesting of identifiers as well so that joining
sub-contexts can get the joined identifiers that apply only to that
specific sub-context.  These identifiers could get long and messy
looking ... wouldn't be for end-user display purposes.  Anyway, anyone
have any thoughts on modifying #2 to state this?

Tom

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 7/25/2006 11:06 AM >>>
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).

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev