Should one model merging of agents?

[williamsonrichard]

It is quite common that entities, perhaps especially public ones, merge. The following link is in Norwegian, but the section 'Ny via sammenslåing' means 'New/Created via merger' and expresses how NAV (a major public entity in Norway) was created in 2006 by a merger of two other entities. This is far from an isolated example.

https://forvaltningsdatabasen.sikt.no/data/enhet/38611

The question is whether this phenomenon is universal and important enough to be worth modelling, so that archival institutions have a common semantics for it, presumably in a way involving rico:isSuccessorOf? Perhaps something like:

Class: rico:AgentCreatedByMerger
  SubClassOf: rico:Agent, rico:isSuccessorOf min 2 rico:Agent

One could also consider using rico:Event as an in-between step to express the merger.

The above class definition could combine quite nicely with object properties as follows.

ObjectProperty: isOrWasSuccessorOfByMerger
  SubPropertyOf: rico:isSuccessorOf
  Domain: AgentCreatedByMerger

ObjectProperty: wasMergedInto
  SubPropertyOf: rico:hasSuccessor
  Range: AgentCreatedByMerger
  InverseOf: isOrWasSuccessorOfByMerger

One then do something like:

Individual: NAV
  Types: CorporateBody, AgentCreatedByMerger

Individual: Arbeidsmarkedsetaten
  Types: CorporateBody
  Facts:
    wasMergedInto NAV

Individual: Trygdeverket
  Types: CorporateBody
  Facts: 
    wasMergedInto NAV

[florenceclavaud]

Hi @williamsonrichard, yes, we have a lot of examples of the kind in France, for public governmental institutions from the French Revolution to nowadays. And I would say this is quite universal a phenomenon. It is also very important from an archival perspective to track the chain of succession between agents, since this often results in a transfer of their records; not to mention this is most often linked to a transfer of functions too. So I would vote for expressing this in the ontology. However, I am not sure I would add a class under Agent. Such succession chains can also occur between persons, or groups, in fact any kind of agent; and a new agent resulting from a merge may also be splitted into others, or merged to another one, etc. I would vote for simply adding a subproperty of rico:isSuccessorOf (and rico:hasSuccessor) and using the rico:AgentTemporalRelation or a subclass of it, to represent this merge. We use this AgentTemporalRelation class extensively here at the ANF; this enables to assign a date and a description to the relation, and to infer the rico:hasSuccessor shortcut. For now we do not differentiate merges, just successions; see for example https://github.com/ICA-EGAD/RiC-O/tree/master/examples/examples_v0-2/NationalArchivesOfFrance - this is a very small subset of what we have on GitHub there: https://github.com/ArchivesNationalesFR/Referentiels). This is my first two cents, and it also reminds me of another work which I had had a look at. Will try to find it back. Anyway this deserves to be discussed! Thank you.

[williamsonrichard]

Great! Thank you for the comments! Interesting regarding rico:AgentTemporalRelation.

One reason that I suggested introducing a class as in my initial comment is that it allows one to express quite precisely that there must be at least two agents involved (rico:isSuccessorOf min 2 rico:Agent); I don't immediately see a way to do this using only a sub-property of rico:isSuccessorOf, but great if there is one!

I completely agree with your remarks about mergers being possible between any kinds of agents (even a merger of two people into a person can make sense, e.g. if those people represent two roles in an organisation!), this is a good point. But I did in fact have this in mind: the class I suggested is indeed defined in general for rico:Agent, it is only the examples which use rico:CorporateBody.

[florenceclavaud]

Hi @williamsonrichard, the rico:AgentTemporalRelation precisely allows you to specify one to many agents as predecessors of one to many other agents, and to describe this merge. And rico:hasSuccessor is just a binary relation, also defined as a shortcut between one of the predecessor to one of the successor - see the following lines: `

        <rdf:Description rdf:about="https://www.ica.org/standards/RiC/ontology#agentTemporalRelationHasTarget"/>
    </owl:propertyChainAxiom>`

So, I just meant that RiC-0 1.0 could include a subclass of AgentTemporalRelation to be used for merge relations between agents. BTW a merge can also concern more than 2 agents (more rarely) ; so 2 agents could be a minimum. And it could also include a subproperty of rico:hasSuccessor (and of its inverse one), defined as a shortcut for the more complex property pathes resulting from a merge relation.

What I just meant is that I am not sure RiC-O should include a rico:AgentCreatedByMerger class. I would tend to consider it a bit too specific to a project, and to let RiC-O implementers define it as a local extension of RiC-O. I mean that while in your project you would like to specifically categorize such agents (group them into a class), some would like to specifically categorize other ones. IMHO RiC-O should provide a generic mechanism to build such classes when needed (which would be the case if we do as I suggested above).

[florenceclavaud]

One more word: it is also probable that we simplify the system of object properties defined as having domain or range a Relation class, and redefine the already defined shortcuts - so that all this should be easier to understand, use and maintain.

[dpitti]

Modeling corporate structure over time is quite complex, as Florence suggested in one of the comments. I would add in addition to merging of two or more entities, or splitting of one entity into two or more, that there are many other ways in which corporate entities change over time. Florence mentioned that transferring functions/activities frequently (and arguably always) is an essential factor in a change in corporate entity identity. It is one of the hallmarks of bureaucracies since the mid-nineteenth century or so to be in a seemingly perpetual state of reorganization. I have seen instances in which functional parts of, let us say, entity A, are split into two separate entities, and an other part of entity A is combine with a part from yet another entity to form a new entity. In the end, if one attempts to model all of the possibilities in order to be precise, it would necessarily be quite complex. I suspect doable, but, again, quite complex. I would be inclined to ask, what would be the functional benefits of such precision? And if you can come up with compelling benefits, then modeling the complexity may be justified. Otherwise, err on the side of less complex.

[williamsonrichard]

Hi @florenceclavaud, thank you for your further thoughts! A little remark touching on the following:

One more word: it is also probable that we simplify the system of object properties defined as having domain or range a Relation class, and redefine the already defined shortcuts - so that all this should be easier to understand, use and maintain.

I confess that in our (reasonably large) ontology, we so far have entirely avoided any (explicit) use of the Relation classes. My feeling has been that these classes are a little heavy to work with, a little too much 'boilerplate' if one will; we have thus far been able to express everything we wished using the more direct implementations of the RiC-CM concepts as object properties. That is to say that we do not think of rico:isSuccessorOf (for instance) as a shortcut; rather it is our preferred modelling of RiC-R016, and we prefer not to rely on inference from a relation class to obtain it.

Whilst this is to some extent a question of taste, I would thus definitely support your suggestion to, if one chooses to add something new to RiC-O expressing merger as a subclass of rico:AgentTemporalRelation, also add a corresponding sub-property of rico:isSuccessorOf :-).

But I think I now agree that it is right, given the design of RiC-CM and RiC-O as a whole, to not introduce a class akin to rico:AgentCreatedByMerger. That is to say that if we introduce a new sub-property rico:wasMergedInto (say) of rico:hasSuccessor, with an inverse which is a sub-property of rico:isSuccessorOf(and these can be connected to Relation classes by composition of properties as you suggest) I agree now that this is probably enough; if I wish to isolate those agents which were created by merger, there is only really one way to do it using these properties, and thus little chance of two archival institutions doing it differently (i.e. little chance of there being an incompatibility in their notions of agents-created-by-merger which would make it difficult to communicate).

I think the only way in which this doing-it-differently might happen is that one archival institution might insist that a merger must involve at least two agents, as I did in my definition of rico:AgentCreatedByMerger, in which case the presence of only one rico:wasMergedInto predicate with a certain object implies that there must be some other such predicate with the same object, we just do not know what it is; whereas another archival institution might be quite happy to make sense of only having one rico:wasMergedInto, e.g. in the case of one entity subsuming another. The semantics of these two points of view are slightly different, and unless RiC takes a position on it, the possibility of two archival institutions not being able to understand one another in this respect exists; but as this could probably be said about many things, and is certainly a quite minor point, I can see that it would be too big of a departure from RiC's design philosophy to try to handle it, at least at the present time.

[florenceclavaud]

Hi @williamsonrichard, for now I would just like ro react to your sentence below:

That is to say that we do not think of rico:isSuccessorOf (for instance) as a shortcut; rather it is our preferred modelling of RiC-R016, and we prefer not to rely on inference from a relation class to obtain it.

I understand this fully. And can also guarantee it works (I mean using the AgentTemporalRelation class extensively, and other classes of the kind, along with the direct relations, may they be inferred or not), even in huge knowledge graphs. Anyway this part of RiC-O should be simplified, and then easier to implement for persons who need to do so.

[florenceclavaud]

Hi @williamsonrichard, about your last remark: "I think the only way in which this doing-it-differently might happen is that one archival institution might insist that a merger must involve at least two agents, as I did in my definition of rico:AgentCreatedByMerger, in which case the presence of only one rico:wasMergedInto predicate with a certain object implies that there must be some other such predicate with the same object, we just do not know what it is; whereas another archival institution might be quite happy to make sense of only having one rico:wasMergedInto, e.g. in the case of one entity subsuming another. The semantics of these two points of view are slightly different, and unless RiC takes a position on it, the possibility of two archival institutions not being able to understand one another in this respect exists; but as this could probably be said about many things, and is certainly a quite minor point, I can see that it would be too big of a departure from RiC's design philosophy to try to handle it, at least at the present time."

I agree fully. Let us keep it as it is, and just add wasMergedInto, as a subproperty of hasSuccessor, plus a subclass or AgentTemporalRelation for implementers who would need such a method. And let us wait and see the feedback and practice of future implementers.

[florenceclavaud]

Let me also mention this ontology, which very precisely describes changes of territorial statistical nomenclatures: http://purl.org/net/tsnchange#.
It is about places, not corporate bodies, and is a French project, not an international, generic, model, as far as I know. I can try and get more information about its current usage. Anyway it focuses on the changes, not the states of the places involved before and after the change. It is interesting, and it would also be interesting to see if it is possible to articulate the model for places, events and relations in RiC-O, with this ontology. For some specfic projects at least it would probably be a good idea. But IMHO it would not be a priority for EGAD to go this way at least for now in RiC-O.

[florenceclavaud]

Closed as completed