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

["Tom Doman" <TDoman@xxxxxxxxxx>]

I'm content if a ContextRef holds enough information to obtain the
"same" context.  Presumably, the "same" context, contains the "same"
policy.  Even though that policy may have changed, it's the policy
that's currently intended for that "same" context.  I think that would
make "sameness" more obvious.  What does everybody think of Jim's
thought?

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 8/15/2006 1:52 PM >>>
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.
 
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 scenario 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 relationship 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