chin-rcip / collections-model

Linked Open Data Development at the Canadian Heritage Information Network - Développement en données ouvertes et liées au Réseau canadien d'information sur le patrimoine
Creative Commons Zero v1.0 Universal
12 stars 1 forks source link

How to model Legal Headquarter Attribution? #49

Open illip opened 4 years ago

illip commented 4 years ago

Currently, our model states:

Companies’ legal and official headquarters must also be documented. This is something that could be done using the E13_Attribute_Assignment class with the following pattern, although it is still under consideration and might change:

Headquarter_Assignment

Questions:

  1. Is it really the address that we should type "Headquarter"? I thought it would be more accurate to type the BuildingX (E24_Physical_Human-Made_Thing) as the headquarter (E55_Type) of CompanyX (E74_Group).

@KarineLeonardBrouillet mentioned that we could have many buildings with the same address so if the entire complex is the headquarter it might be a better idea to attach it to the address instead of the building. In this case, I think we could see the whole complex as a E24 and still attach the headquarter to it.

  1. I also think that the building node is important to link the headquarter to the proper group. In my opinion, this link is not necessarily represented in the diagram because, I believe, in some cases it might be another E39_Actor than the E74_Group who performs activities in this building that attributes the headquarter type. Let's say the CEO attributes the type headquarter to his/her company.

  2. Finally, I'm not sure how we are using the E13_Attribute_Assignment in this pattern. As I understand, the E52_Time-Span on this node represent the attribution activity so the "beginning" when this type becomes true. It's not representing the period where this attribute is valid. So in this case, if we want to change the headquarter from BuildingX to BuildingY, it's impossible to express that BuildingX is no longer the headquarter.

What do you think?

KarineLeonardBrouillet commented 4 years ago

I would add that sometimes corporations lease headquarter space to other entities when they have unused premises, or themselves rent premises if they are missing office space for example. So I think there is also a distinction to be made between "official" headquarters and actual "real use" headquarters. That said, this might not be a distinction we need to represent :)

Habennin commented 4 years ago

@illip I think you are right that it might be better to specify the building. The question is what question does this answer? If the question is 'which address do I send / did someone send a piece of post to if they wanted to get it to headquarters' the pattern above is great. If the question is 'in which jurisdiction did x register itself for tax reasons' maybe using the building (which then should have place information) might be better.

About the timespan question, if you want to make sure that you can document that something is no longer the headquarters then the 'identifier assignment' class (which would be appropriate) also has a 'de assigns' property. Or you could use the frbr class for name use.

I guess the modelling really hangs on the question of what people want to ask of this information.

TrangDg commented 3 years ago

Diagram is removed from Version 2.1, to be included in future version.

marielmat commented 3 years ago

The proposal of @Habennin (specify the building + place information) seems appropriate to me. But I wonder what questions we want to answer...

Since we document our collections from the artifact - not the Actor - the first information we record about a manufacturer (e.g. Kodak) will be that which is written on the object. If a projector is manufactured by Kodak Canada Limited, I have a record for that entity, but it is not linked to its headquarter Eastman Kodak Company - Could Kodak Canada have its own headquarter?... We do not have a master record to link subsidiaries to their headquarter - we are discussing about if we implement this kind of link or not)

With a better relationship between the headquarter and its subsidiaries, I would like :

These are examples that come to mind, but their answer depends mostly on our ability to link the subsidiaries with the headquarter... For now, the address seems to me only useful to create visualizations in the form of a map.

For your information, here is how we enter the information.

At the top, a main form where we document the name and dates. Followed by a section with the address. For example, we could (but don't really do it) document when an address is valid or stops being used (Begin Date - End Date) or the type of address (eg. we could create a type "Headquarter address")... The problem with us is the variety of our collections (artifacts, books, archives...). It implies to look at how many records would benefit from better documentation of their addresses. And if we decide to go ahead or not with a project of this type. I just want to point out that we have a lot of fields that would allow us to be very specific about the location of an organization.

Christian-McCord commented 3 years ago

Nous fonctionnons de la même façon que l'explique ici marielmat. Nous documentons prioritairement les objets. Toutes informations inhérentes à un édifice proviennent de l'objet et sont répercutées dans la section "Addresses" de la fiche Actor. Nous utilisons essentiellement deux types d'adresses: "Personal address", "Professional address". Toutefois, aux fins de datation, par exemple, des photographies de la filiale "Notman" à Ottawa, la fiche Actor est nourrie d'informations tirées d'annuaires commerciaux retraçant les administrateurs et les années d'activité de cette branche. Le "siège social" n'est pas nécessairement identifié, sauf parfois dans un texte libre (Notes ou Curatorial remarks de la fiche objet).

image

image

illip commented 3 years ago

The Semantic Committee has decided on 2021-04-01 to keep the headquarter mention as simple as possible for the moment since we do not have any strong use cases that require a more semantic pattern. So the decisions are:

  1. Define more clearly what we intend by "headquarter" which we think should be related to our Stay pattern. So in other words, the headquarter is used to type an activity that occurs in a place, but not the place per se.
  2. We will use P21_had_general_purpose to make the link between the E7_Activity (Stay) and the E55_Type (Headquarter).