Re: Organization hierarchy

Hi James, 
sorry for the delay,
No, parent_id could implicitly mean the current parent, I think the benefit is not enough to outweight back (or standard) compatibility.
Maybe parents could be renamed parents_history, just in order to signal the semantic difference between the two similarly named fields.

Guglielmo

Il giorno 09/set/2013, alle ore 18:08, James McKinney <james@opennorth.ca> ha scritto:

> I was considering keeping parent_id for the current parent. We could rename it to current_parent_id, but the benefit in terms of clarity needs to outweigh the cost of changing current implementations. What do you think?
> 
> 
> On 2013-09-07, at 2:22 AM, Guglielmo Celata wrote:
> 
>> You're right, the children property is not necessary at all in the protocol. 
>> It is an implementation mechanism I use it as a cache, in order to reduce the number of queries in the DB.
>> 
>> I agree with the proposed implementation, as shown in the ticket (the child_id refers to the current document).
>> I would add a current_parent_id property, though, just to keep compatibility with code using the standard parent_id representation for trees.
>> 
>> Guglielmo
>> 
>> Il giorno 06/set/2013, alle ore 20:43, James McKinney <james@opennorth.ca> ha scritto:
>> 
>>> Thanks, Guglielmo.
>>> 
>>> Is a "children" property necessary? It's possible to traverse a tree using only a "parents" property. It's a little more error-prone to have to maintain the organizational hierarchy in two fields instead of one.
>>> 
>>> I've created an issue in the tracker: https://github.com/opennorth/popolo-spec/issues/41
>>> 
>>> James
>>> 
>>> On 2013-09-04, at 5:53 AM, Guglielmo Celata wrote:
>>> 
>>>> I understand the *preoccupations* (forgive my limited english vocabulary) regarding the standard parent_id case, which indeed would cover 9 out of 10 use cases.
>>>> What we came up with in some of the projects is de-normalizing the database, and it's pretty much the solution you're proposing.
>>>> 
>>>> So, for example, the Organization model would still have a parent (or parent_id) attribute, that I would call current_parent, for clarity.
>>>> The JSON serialization explicitly would contain both an array of parents and children, with start and end dates, extracted from the external Relation model.
>>>> The current_parent would usually be the last element of the parents list, and it must have a Null end_date.
>>>> 
>>>> This would allow to represent time-dependend father-child compositions.
>>>> 
>>>> 
>>>> An example (pseudo-python) for an organization with parentships changing dynamically over time:
>>>> 
>>>> Organization
>>>>  { id: ID,
>>>>    current_parent_id: PID3,
>>>>    parents: 
>>>>    [
>>>>      { id: PID1, start_date: '2006/07', end_date: '2008/09/01' },
>>>>      { id: PID2, start_date: '2008/09/02', end_date: '2012/04' },
>>>>      { id: PID3, start_date: '2012/04', end_date: NULL },
>>>>    ],
>>>>    childresn: []
>>>>  }
>>>>     
>>>> 
>>>> 
>>>> 
>>>> As for N-N aggregations, it's a very rare use-case, in the institutional context we're focusing on, I can only think of 
>>>> a rather stretched example.
>>>> 
>>>> Since in Italy there is a minimum number of MPs required to form a group (in both chambers of the parliament), 
>>>> we have a so called mixed group, with members from various small (usually regional) electoral parties.
>>>> Now, from time to time, an MP exits from a big group and enters into the mixed group, usually a few months before
>>>> passing into another different big group alltogether, just in order to disguise the actual flip.
>>>> 
>>>> If I want to know the composition of the mixed group at any given time, in terms of electoral parties, a single party could easily be into two groups.
>>>> The electoral party as an organization exists independently of the parliament groups.
>>>> 
>>>> Of course I could just count the memberships and obtain the same result, but I was just trying to make an example.
>>>> In other contexts these situation could arise more frequently.
>>>> 
>>>> I would agree in considering aggregation issue a minor one.
>>>> Given the focus and context of the popolo project, it could be left out of the specs.
>>>> 
>>>> 
>>>> Guglielmo
>>>> 
>>>> 
>>>> 
>>>> Il giorno 04/set/2013, alle ore 00:46, James McKinney <james@opennorth.ca> ha scritto:
>>>> 
>>>>> 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
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>