Re: [higgins-dev] DigitalSubjectRef (was What is a relationship?)

["Tom Doman" <TDoman@xxxxxxxxxx>]

I'm not looking for guaranteed existence, rather where you were going
with your last paragraph.  That is, that the ContextRef+CUID would get
me to the same Digital Subject, if, in fact, it still existed.  Yes,
however, this would require no recycling of CUIDs.  I'm not sure why
that's too restrictive, I think it's required.  Our Digital Subject
relationships better not suddenly reference some other Digital Subject
because a CUID got reused.  This is why I was asking about the
representation of relationships earlier.  One of the three parts is a
DigitalSubjectRef, not an actual DigitalSubject, the DigitalSubjectRef
has to be valid for an indeterminate amount of time ... preferrably
forever, IMHO.

Tom

>>> Greg Byrd <gbyrd@xxxxxxxx> 8/15/2006 2:12 PM >>>
Jim Sermersheim wrote:
> So basically, we need to make sure that a DSRef is able to be
resolved 
> to the right DS in the right Context (whatever "right" means).
>  
> I guess the solution could go the way Tom is thinking (add another 
> part to IDigitalSubjectRef), or we could just say that the ContextRef

> (URI) holds enough information to obtain the "same" context. 
>  
> We've already established (http://spwiki.editme.com/ContextRef) that

> two equal ContextRefs will produce "same" contexts. Is it fair to add

> that given two "same" cuid's and two "same" contexts we can produce 
> two "same" DigitalSubjects? If so, problem solved. If not, then I 
> think it's not right to say two same ContextRefs produce two same 
> Contexts.
I think that's all we should require.  To do more than this, IMO,
places 
a significant burden on the Context implementation.  A DigitalSubject 
that exists now might change or might not exist in the future.  The 
Context should not be required to save all referenced versions of the 
DigitalSubject to preserve some view from the past.  If the consumer 
cares about this, it can create a complete copy of the DigitalSubject
in 
its own "permanent" local Context.

Analogy:  If I login to my computer as root, I can see files that don't

appear to exist if I login as gbyrd.  But that doesn't mean there are 
two different file systems.  It just mean that I have a different view

of the contents of the file system.   Using the same analogy, Unix does

not guarantee that a file looks the same the next time I read it, even

if it has the same name.  And there's no guarantee that I'll be able to

recover the old contents of that file if it changes -- if I care about

the contents at a particular instant, then I'd better make a copy. 

Can a Context reuse the CUID of a DigitalSubject that has been removed?
 
If so, then we can't assume that today's URI+CUID will refer to the
same 
DigitalSubject as tomorrow's.  But to say that a CUID can't be recycled

seems too restrictive to me.

...Greg

>  
> Note that "sameness" isn't obvious (as Tom started pointing out). The

> non-static nature of DigitalSubjects and the fact that we're not 
> passing around authN/authZ materials and policy along with references

> will cause two same contexts to possible produce different views of 
> the "same" DS (one Context may not even produce the DS at all!).
>  
> Jim
>
> >>> "Tom Doman" <TDoman@xxxxxxxxxx> 8/15/06 9:40 AM >>>
> OK, cool.  Another point I'm considering.  Any given context
provider
> may have policy\configuration\metadata (whatever we're calling it)
that
> governs the creation of Digital Subjects from that context.  For a
> simple example, policy may constrain the attributes that are allowed
to
> be presented in any given Digital Subject produced from a given
context.
> Is any resulting Digital Subject only as long lived as the policy
which
> governed it's creation?  Certainly any given Digital Subject's
> attribution may change at it's source and yet it remains the "same"
> subject.  A change or removal of a governing policy will produce a
> "modified" Digital Subject as well.
>
> So, a long way to the question ...
> Should we allow for the optional specification of a policy URI in
> IDigitalSubjectRef?
>
> This may be more important in the scen ario where a given Digital
> Subject is the result of a join where what is joined from which
sources
> is governed by policy which may change.
>
> I guess it comes down to this question ... As a consumer of IdAS,
how
> am I sure that a given DigitalSubjectRef I've remembered will
produce
> the "same" DigitalSubject each time?
>
> Tom
>
> >>> Greg Byrd <gbyrd@xxxxxxxx> 8/14/2006 11:31 AM >>>
>
> It's both.  It is between DigitalSubjects, which may represent the
same
>
> entity or different entities.
>
> We don't have the notion of a "persona" of a DigitalSubject.  A
> DigitalSubject is defined solely by its Context.  "Home Tom" and
"Work
>
> Tom" are different DigitalSubjects, though they both represent the
same
>
> entity.  So a relationship between "Home Tom" and "Work Tom" is a
> relationship between distinct DigitalSubjects, as you state in item
(1)
>
> below.   But the type of the re lationship could be "SameEntity", or
> something similar that represents your item (2).
>
> ...Greg
>
>
> Tom Doman wrote:
> > What is the semantic intent of the "relationship" construct
between
> > IDigitalSubjects?  Is it:
> >
> > 1. Meant to convey some association to other distinct
> IDigitalSubjects?
> >  As in, Jim has a coworker relationship with Tom.
> > 2. Meant to associate distinct personas of a single
IDigitalSubject?
>
> > As in, Tom has a "work" persona and a "home" persona.
> > 3. Both?
> >
> > I ask for this clarification for a follow to the ContextRef+CUID
> > discussion which is right in line with my e-mails about "Unique
> > Identfication of Amalgamated Digital Subjects".  I see this
> discussion
> > as just another case where we have to work out unique
identification
> > issues.
> >
> > Thanks,
> > Tom
> >  
>
> ______________________________ _________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
>
------------------------------------------------------------------------
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
>   

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