RE: [higgins-dev] Revised Higgins data model goals

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

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. Not an explicit Context to Context relationship. On the other hand, you say Raj and Tony want explicit relationships. 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?

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

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. 

The expounding I was looking for was an example of where an application (or user) would need to access 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.

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