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

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Jim wrote:

> 
> >>> paul@xxxxxxxxxxxxx 4/18/06 6:55 PM >>>
> <snip>
> 
> >(b) In a second use case the same person Entity may have
> DigitalSubjects in
> >multiple contexts. They may have a root context with a root
> DigitalSubject
> >that consists mostly of references to its other selves (other
> >DigitalSubjects) in other contexts. In this case you would expect a
> kind of
> >attribute inheritance model where the DS in the root context
> inherited
> >attributes from its N sub-DS's in other Contexts.
> 
> Ok, I get that. Though, (tangential rathole alert!) introducing the
> notion of inherited attributes starts sounding like a mix between a
> "joined" context, and a set of purely related DS's. I like it, but
> allowing all three scenarios to exist may confuse applications. For
> example, an application may interrogate a DS, discover a number of
> attributes, as well as some relationships to other DS's. Assuming the
> application can determine that these relationships point to sub-DS's,
> how would it know whether it needs to interrogate those as well, or if
> the context provider has done the work of virtually inheriting the
> attributes from the sub-DS's?

Yes, this is a great point. We'll need to tread very carefully as we build a
little and try a little. We know we need the raw power to support various
use cases we have, but we don't know yet how to not, as you say, confuse the
app.

> 
> <snip>
> 
> >> Is there a goal to have the notion of Context hierarchy in Higgins?
> Or
> >> is the space of Context's flat? If a hierarchy can be modeled, how
> is
> >> the parent/child relationship indicated (on the context
> relationship
> >> element I imagine). Are there use-cases that require a hierarchical
> >> relationship? Is there a max depth to a hierarchy?
> >
> >Context hierarchies can be expressed, though other non-hierarchical
> >relationships are possible. The use cases that motivated this are
> directory
> >cases, e.g. an "department" context might have "sub-department"
> contexts.
> 
> I see, so this could be done by having relationships from DS to DS
> (each representing directory nodes), or Context to Context (again, each
> (or some) representing directory nodes). The way it's represented would
> be up to the context provider and/or its configuration. I'm still not
> sure I see the benefit of using an explicit Context to Context
> relationship to do this, but I think I need to think more about it. In
> any case, I can see that a relationship should be able to denote
> hierarchy. 

Well you and the other folks with directory experience need to mull this
over. The idea of Context-to-Context relationships is for the
organization/dept kind of distinction where there probably is NOT a
correlated DS in both the org and the dept.

> This, I assume would be done by some kind of "type" metadata
> on the relationship. 

Yes. Thanks to [4] all relationships are uniquely identifiable and thus able
to be overlaid with "type" via a schema (rather than the more awkward
explicity attachment of metadata data to the relationship itself.)
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev