Open illip opened 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 :)
@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.
Diagram is removed from Version 2.1, to be included in future version.
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 :
to know the distribution of the company around the world (or some country, province...),
to see the evolution of, for example, the disappearance of family businesses after the arrival of a bigger player
to have an idea of the type of products manufactured by the company, according to their geographical locations
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.
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).
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:
P21_had_general_purpose
to make the link between the E7_Activity
(Stay) and the E55_Type
(Headquarter).
Currently, our model states:
Questions:
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.
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 theE74_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.Finally, I'm not sure how we are using the
E13_Attribute_Assignment
in this pattern. As I understand, theE52_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?