Jim wrote:
Yeah, the org example points at the need is where (as Paul
pointed out as well), some kind of relationship needs to exist and it may not
make sense to draw it at the DS level.
Jim
>>> Nataraj Nagaratnam <natarajn@xxxxxxxxxx> 4/18/06 9:44 PM
>>>
Yes,
context relationships need to be managed - whether they are hierarchical or not
depends on the relationship, and importantly, like Jim was pointing out,
depends on the semantics of the consuming application and applicable policies.
Thinking of an example - would we characterize Higgins
as a sub-context to Eclipse in org sense? Does that mean all policies
applicable ot Eclipse are applicable to Higgins? Does it apply to membership?
access list? Probably not everything. So, there are relationships.. and
information about relationships that may identify some hierarchy in
organizational structure, geo affinity (NC, UT, MA are states in USA), etc.
Raj
|
"Paul Trevithick"
<paul@xxxxxxxxxxxxx>
Sent
by: higgins-dev-bounces@xxxxxxxxxxx
04/18/2006 09:14 PM
|
Please
respond to
"Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
|
To
|
"'Higgins (Trust Framework) Project
developer discussions'" <higgins-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE: [higgins-dev] Revised Higgins data model
goals
|
|
Jim wrote:
>
> Oh, now I see two discussion points
(different types of relationships, and
> the notion of hierarchy):
>
> In your description of Mary's example, you're
talking about context
> relationships as they are implicitly
formulated via references on a
> DigitalSubject.
Yes.
> Not an explicit Context to Context
relationship.
Right.
> On the
> other hand, you say Raj and Tony want
explicit relationships.
Raj and Tony want the option to be able to express
explicit Context to
Context relationships that may or may not be
hierarchical.
> These are
> (in my mind) two different kinds of context
relationships. (Q1) In the
> data model, are they seen as being lumped
together in the same set?
The Raj/Tony kind are supposed to be captured with
[10]: Contexts are
associated with other Contexts in 1:1 or 1:M
relationships.
The other kind isn't explicitly stated anywhere.
Perhaps we need to add back
in an explicit separate goal related to the
ability to unidirectionally
correlate DigitalSubjects across contexts and to
the "implied" Context to
sub-Context relationships that are thereby implied
by the DS-to-DS
unidirectional relationship?
>
> In both of these you mention hierarchy where
the target is subordinate
> (maybe you didn't mean to say
"hierarchy" in #2 below when describing Raj
> and Tony's case). (Q2)Anyway, what is the
benefit of using hierarchical
> terms (subordinate, superior, parent, child)
to discuss these
> relationships? If there is none, my fear is
people will begin to
> imagine/assume hierarchies where there are
none, or be confused that
> hierarchies appear to change (any hierarchy
is only valid from the
> perspective of a given DigitalSubject * as if
you grabbed a node of a
> graph and lifted it up until all the attached
nodes dropped into a
> hierarchy).
Since DS-to-DS relationship links across Context
are uni-directional then
there is a "directedness" in the
relationships between their respective
containing Contexts. This *is* a kind of
hierarchy, though an implicit one.
The Raj/Tony explicit Context-to-Context 1:1 or
1:M may or may not be
hierarchical.
>
> I guess what I'm saying is, this kind of
hierarchy can be imposed and
> viewed by a consuming application without us
using hierarchical terms in
> our model, and it might be safer that way. By
safer, I mean this: In X.500
> / LDAP, the data model has the notion of
hierarchy. This is exploited to
> overlay different types of semantics (i.e. A
policy applied to one node is
> assumed to be applied to all nodes below it).
Overlaying semantics works
> great when everyone agrees on the hierarchy,
but in reality, hierarchy,
> and its myriad of implied semantics becomes a
political nightmare. So much
> so, that people often shy away from using
hierarchy for anything, and
> instead, drawing their own semantic-specific
relationships (which is what
> I assumed this data model was striving to
allow).
>
> Sorry, I'm rambling about this hierarchy
stuff, it's not (nor are any
> hierarchical terms) even mentioned in the
revised goals.
I'd be interested in what Tony and Raj think about
what you're saying here.
Maybe this is what was behind them stating that
the Context-to-Context
relationships are definitely not necessarily
hierarchical. Perhaps they were
thinking they should be more loosely associated
and then let, as you say,
the apps/policies fight it out at their level.
>
> The expounding I was looking for was an
example of where an application
> (or user) would need to acce ss the context
relationships. I'm just trying
> to understand the justification for that
aspect of the model. With my new
> understanding, it would also be good to
clarify Q1 above as well.
Okay.
>
> Jim
>
>
> >>> paul@xxxxxxxxxxxxxxxxx 4/18/06
6:12 PM >>>
> 1) Mary describes a *hierarchical* kind of
1:1 or 1:M relationship. When I
> was discussing this point with Raj and Tony
they also envisioned
> non-hierarchical 1:1 and 1:M relationships.
>
> 2) There are two kinds of hierarchies in
Mary's example. A DigitalSubject
> in
> one context might have (unidirectional)
references to a DigitalSubject in
> another context. From this subject's perspective
the latter is a "sub"
> context of the former. This is a kind of
implicit Context hierarchy. The
> other, which is what Raj and Tony had in mind
in 1) above is an explicit
> Context hierarchy (never mind whether there
are any DS to DS relationships
> between them.
>
> Jim: I'm not sure what kind of expounding
would be helpful. Let me know.
>
> Mary wrote:
> >
> > A context can have a subcontext (1:1) or
multiple subcontexts (1:M)
> >
> > For example, there might be a context
associated with a particular
> > system, and a person may be
participating with that system in multiple
> > subgroups: a My Base Ball Fan
Yahoo group and My Neighborhood
> > Association Yahoo group.
> >
> > Or a context created for participation
at a conference may be structured
> > with subcontexts: one of which
corresponds to the person's role as an
> > attendee, one their role as a presenter,
and one designed for any
> > visitor to the conference city.
> >
> > >Can we expound on [8] Contexts are
associated with other Context s in
> > 1:1
> > >or 1:M relationships?
> >
> > >I know there may be objects in a
context which show relationships to
> > >objects in other contexts, and
that's one way we might have context to
> > >context relationships, but this goal
(I think) is talking about direct
> > >relationships.
> >
> > >What it looks like is someone will
want to, given a context, see what
> > >other contexts are related. If so,
what will they do with that
> > >information? One case may be where
the Contexts are actually replicas
> > of
> > >one another. In that case, the
consumer of the context relationship
> > >information is storing failover
information. Probably not the use case
> > >that drove the goal.
> >
> > Jim
> >
> >
> >
> >
_____________________________________________ __
> > 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
