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

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

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

<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. This, I assume would be done by some kind of "type" metadata
on the relationship.