Re: Organization hierarchy

Hi Guglielmo,

For your second question about aggregations (N-N relations between organizations), can you give an example from your work where this is the case?

For the first question: indeed, there is an issue in the tracker: https://github.com/opennorth/popolo-spec/issues/27 Very few existing standards handle changes over time, so we will likely have to come up with our own solution like the one you suggest.

The relation you propose would work. It's actually very similar to a Membership in Popolo. (Perhaps an eventual solution would have a Relation superclass with your new class and Membership as subclasses.)

The challenge when dealing with historical use cases is to make sure that the common use cases are still easy to implement. Here, a common use case is to represent the *current* organizational hierarchy/tree/graph. There already exist many treelibraries in various languages for storing tree structures in databases. Most of these have no method of tracking changes over time, and use a single field like "parent_id" to track the tree structure. An ideal solution to the challenge would allow people to continue to use such libraries.

Perhaps a solution would be to maintain "parent_id" and "parent" as-is, and to add a new "parents" property, whose value is an array of Relation objects? Implementations can then choose whether to implement either "parent_id" or "parents" or both.

Depending on how the aggregations issue is resolved, it may make sense to encourage the use of "parents" only.

Would anyone be against eliminating parent_id, if that were part of a solution?

James

On 2013-09-03, at 9:38 AM, Guglielmo Celata wrote:

> James,
> the Popolo protocol currently allows hierarchical relations between organizations to be mapped through the parent_id attribute.
> 
> One possible shortcoming is that this is a permanent relation (it has no start nor end dates), and sometimes, especially in political groups, relations do depend on time.
> 
> Another lesser shortcoming is it maps compositions (a group, or a big company and its departments), but leaves out aggregations (members can join more than one group).
> 
> In a relational world, I would map it with an external entity:
> 
>     ------------
>   1|            |N
>  -----        -----
> | Org |------| Rel |
>  ----- 1    N -----
> 
> Where Rel is the relation and it would have these fields:
> id
> from_id
> to_id
> start_date
> end_date
> 
> from_id and to_id are references to the Org, organizaiton entities.
> 
> Don't know how it would translate into the protocol and if the complexity it introduces are worth the issues it tries to solve. 
> 
> 
> Any ideas?
> 
> Guglielmo Celata
> Developer
> Associazione Openpolis
>