Hannes, The system uses the mergenode information to define the shape of the graph for each instance of a given resource. (Per Alexei’s drawing.)
You are right that you could set every merge node to the root of the graph (the resource itself) and never see any difference in the function of the application as a user. The reason that a developer would want to enforce the shape of resource instance graphs is in order to enforce compliance with CRM (or some other ontology’s) standards. In the case of HIP, the merge nodes we implemented were the result of thoughtful comparison of the data we want to store, and the “level” of CRM-compliance that we wanted to meet for data stored within Arches. I (or Alexei) will spend a little bit of time expounding on your ACTOR example, but I wanted to get this high level explanation back to you sooner rather than later. Best, Adam -- Adam Lodge Geospatial Systems Consultant Farallon Geographics On Wednesday, July 15, 2015 at 8:00 AM, H Pirker wrote: > Hi Alexej > > Thanks a lot for your explanations. > > Your ASCII-Art was very helpful to understand what is going on in terms of > *graphs*. > > But I still have not completely understood what are the real consequences of > the different graphs when it comes to the concrete data-modelling in a real > application. > > Could we take again the concrete example of the Resource Graph ACTOR.E39: > The mergenodes there are: PLACE.E53, APPELATION.E41 and ARCHES_EVENT_PHASE.E4 > > END_OF_EXISTENCE.E64 e.g. is NOT a merge node. > > > > As END_OF_EXISTENCE.E64 e.g. is NOT a merge node, it's child nodes (e.g. > END_OF_EXISTING_TYPE and END_DATE_OF_EXISTENCE) would end up in separate > sub-trees directly attached to the root node? Or they doen't because they > always are entered together in one input form. and the code there makes sure > that END_TYPE and END_DATE become not separated? But then again, if this > would have to be taken care of in the code anyway, what would be the role of > the mergenode? > > Also: I cannot "see" any difference for those sub-trees *with* mergenodes > (e.g. APPELATION) and those *without* (e.g. END_OF_EXISTENCE) in the > surface-behaviour of arches-hip: they don't behave differently in the input > forms (I can add multiple NAMES and multiple birth-dates to a person)? > > > The system itself will allow you to save any shape graph you want (correct > > or otherwise). It's up to you as a developer to understand the intent of > > the graph shape and then use the mergenode information to achieve that goal. > > > So do you mean, that the merge-node information is not used by the (current) > system at all, and that it is only there to *inform* the programmer of the > data-modeller's "intention"??? > > all the best > > Hannes > > > > > > Am Dienstag, 14. Juli 2015 11:53:15 UTC+2 schrieb H Pirker: > > Dear all, > > > > Can somebody comment on the role & purpose of "mergenode" in Resource > > Graphs. > > > > In the documentation ( > > http://arches3.readthedocs.org/en/latest/arches-data/#resource-graphs ) it > > just says: > > > > > mergenode: defines the upstream node that occurs one time (and only one > > > time) within a given resource instance. In most cases, that node is the > > > one that represents the resource itself. > > > > When inspecting an existing graph. e.g. ACTOR.E39 I can see that the > > mergenode depicts the root of "useful" sub-graphs, i.e. for PLACE, > > APPELATION and ARCHES_EVENT_PHASE. > > > > But what are actually the consequences of adding mergenodes - or leaving > > them out? Is it used and/or required for specifiying "required" and > > "unique" (""one time (and only one time)" ) ? (But this would mean, that > > only a SINGLE ARCHES_EVENT_PHASE can be assigned to a ACTOR, which seems > > odd ?) > > Why do some sub-graphs have a mergenode, while others just "merge" with the > > root-node of the whole Resource Graph ? (e.g. > > BEGINNING_OF_EXISTENCE_TYPE.E63) > > > > yours puzzled :-) > > > > Hannes > > > -- > -- To post, send email to [email protected] > (mailto:[email protected]). To unsubscribe, send email to > [email protected] > (mailto:[email protected]). For more information, > visit https://groups.google.com/d/forum/archesproject?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Arches Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > (mailto:[email protected]). > For more options, visit https://groups.google.com/d/optout. -- -- To post, send email to [email protected]. To unsubscribe, send email to [email protected]. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
