- From: Guglielmo Celata <guglielmo.celata@gmail.com>
- Date: Wed, 4 Sep 2013 11:53:12 +0200
- To: James McKinney <james@opennorth.ca>
- Cc: public-opengov@w3.org
- Message-Id: <409DD410-4ED7-4450-80B6-778D30031FCB@gmail.com>
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 >> >
Received on Wednesday, 4 September 2013 09:53:43 UTC