New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move, Sojourn, Acquisition, Establishing: how to model the geographical presence of Actors? #31
Comments
This is the continuation of Issue #18. As discussed, the Sojourn pattern does not suits well for groups like companies, but would it work also fo smaller informal groups like artists groups. |
I dislike the use of a sojourn pattern simply because it seems likely to induce errors (from what you mention above). I would be against using the |
At first glance, I would vote for I know that For the groups, I don't know exactly how museums are normally documenting these grouping travels but in fact it's not the group who is moving but the members of the group. How can we state that X artist group was in Paris from this date to this date? If there is one member missing, do we still have the right to say that the whole group was in Montreal? If all the members of the group are in Paris but for personal vacations, can we say that the group was there? All this to say that I would prefer to stay with the real estates of the groups and theirs members can move. It might be difficult to manage records where no information is available about the member though. But semantically, I still think that a group cannot move. By the way, if we decide that it would be easier to be able to move groups, why we don't use |
Indeed, the The acquisition pattern is good enough for companies that owns buildings, but could we use the In the case of a the group of artists that are know to meet in a café, and that establish this location as their general quarters, should we document this café as their location? If so, I think the To summaries my opinion:
|
What are the use cases that drive these different patterns? If you have four different kinds of things to document, you may just end up with four different patterns. Are there existing fields that need to be translated from artefacts canada? |
Just to keep this ball rolling... What are the real world situations?
For 1) Sojourn pattern works and you can ask and answer questions like when did so and so live in paris, when in montreal, when on hydra? For 2) Move pattern works and you can ask and answer questions like, where has so and so been, where have they travelled, where were they travelling in 1999 etc. This is a semantically different set of questions from where have they lived. For 3 and 4) Establishing pattern would work because you would be able to say that a group or business chose to set up here at this time and there at this time. However, if you don't want to create new classes (encouraged by the CIDOC CRM manual if you need something new), you could broaden the meaning of the sojourn pattern as per part of Philippes sugesstion. I would not go so far as to collapse ALL of the meanings because E9 Move allows you to capture trajectory of real physical objects as they move through time and space. How far did Terry Fox run on day 3 of his famous journey? What places did he pass through? These questions cannot be answered except if you have the capacity to semantically represent the movements. |
Notes on verbal meeting held 2020-02-17: Maybe could be reduced to two patterns because: Or you want to know somebody could be found in this region at this time and this can be modeled as a sojourn pattern that should then be renamed. This would be a cleaner solution. Stephen trying to gather use cases but there is not much so we do not yet have a clear picture of what would be best. It could work either for a person or group. Habennin was thinking of logic because of L. issue about property chains. It would be interesting to build some logic. It would be a good solution for pc14 problems. CRM SIG does not produce. No digital place: Appellation-address-for a meeting. URL can be considered as an address for simple cases. No place for Second Life for example. |
I have a doubt about Chin:establishing: why not use the standard crm class Group Formation? http://www.cidoc-crm.org/Entity/e66-formation/version-6.2 |
@VladimirAlexiev, by chin:Establishing we don't mean the formation of a group. Again, it will be easier to follow when our model will be released, but the general idea was to have a pattern to associate groups and places where they are "actively working" without going through an aquisition event. In other words, something less formal (e.g. this artists group met every week in this coffee shop). The reason is that we have a lot of use cases where a group didn't purchase a property per se. They can rent something or just hang out somewhere. To all, did we get a consensus on this one? If so, it's not clear in the issue. I would vote to use I think @Habennin pointed out all the potential use cases, but I would really like to find some concret examples in our data. Did I miss something? |
Ok, so it's like "floruit" but for Groups. You guys should use:
Examples:
Properties (in addition to place/timespan inherited from
This is defined in FRBRoo v3.0 (October 2017). LRMoo (f.k.a. FRBRoo) v.0.6 (February 2020) says "Transferred to CRMsoc" but I don't know where that ontology is. LRMoo is a DRAFT so until it settles down, feel safe to use Now what do you mean by "Sojourn"? From the name I thought you intend to use it for Grand Tours or perhaps http://vocab.getty.edu/aat/300393197 Gap Years (sabbaticals or journeyman years)? (I'm probably completely mistaken). Please consider this: http://vocab.getty.edu/doc/queries/#ULAN_Events_by_Type (an up to date result). It lists maybe 40 types and I think you should specify these should be used as |
Establishing for Groups@VladimirAlexiev The idea for this pattern is to document the geographical location of Actors. That means the physical location for To clarify this, two simple examples:
With those two examples, we need to document the The We could use multiple Sojourn for PersonsThe idea behind "Sojourn" is the same. Probably the naming of that event is not the best, as it is misleading. The goal of this "Sojourn" event is to document the presence of a We need to rename this type of Activity. Types of ActivitiesThank you very much @VladimirAlexiev for this Events by Type, it is indeed very useful for our |
@illip I think that multiple Pursuit activities fit the need of "had store", "had factory" etc, and you don't need a custom class Establishing. Of course, qualified with P2 to describe what it is. On the other hand, you can simply use Activity which is more neutral. If you just know that person was at that place but not what he did there (maybe Riopelle just partied in Paris?) then Activity is more appropriate, while reserving Pursuit for the overall period of Floruit. BTW, ULAN event types include one named merely I agree that capturing the periods is more useful than recording a bunch of Moves (which are bound to be incomplete). |
I think I left out one of the scenarios which was key to the argument for 'establishing', around corporations. The idea was that you might, for example, want to document the growth and decline of the Sears organization (E74) in Canada. Originally the option of move was considered because it allows one to connect organisations to places. But this is incorrect because E74s do not (typically) physically move and anyhow the semantics would be wrong because in establishing new stores Sears does not leave one place and go to another, rather, it 'establishes' itself in new places. So this situation is again different from the scenario of groups (in the sense of collectives of people) hanging out in a location, but rather is about tracking where an organization is and is not over time. It is true, however, that an alternative would be to build some of general F51 class which is the total event of the business operations of Sears and then use a partition property to indicate the various moments in which Sears set up its first location in Lac La Biche or Shawinigan. As stated elsewhere, but bearing repeating however, there is 0 prohibition and in fact encouragement to extent the CIDOC CRM when you require a new property in order to accurately capture your information. If following corporate history and the precise extension of Sears like activities in Canada through time is a real use case then it is perfectly legitimate for it to motivate your own new classes and properties to capture this (CIDOC CRM was not originally designed to cover corporate history). If indeed you go in this direction then this would probably be something that should be brought to the attention of the developers of CRMSoc who might eventually incorporate such patters into this planned official extension: http://www.cidoc-crm.org/crmsoc/ |
@Habennin One is not completely free to create whatever custom classes and props.
This said, it would be fine to create sub-classes of Activity or Pursuit for specific situations, but only when P2 is not enough to distinguish. Thanks for mentioning CRMsoc! I didn't know about it. The pages are still not fleshed out, but there are 2 useful:
|
Of course, CHIN is in favor of creating new classes and properties when it's relevant to do so. However, we are also aware that maintaining and advertising those new entities might be a challenge since we don't have unlimited resources. In this particular case of
@Habennin What do you think? |
Hi - AC will not have existing fields for this, as it is focussed on documenting objects, although there are merchant/manufacturer fields. For example there is a Merchant Address field: https://app.pch.gc.ca/application/ddrcip-chindd/field_detailler_terme-term_field_detail.app?rID=1250&dd=sh-hs&fID=2&ac=false&lang=en&qlang=en&fl=GR&tne=ARTIST%2C+MANUFACTURER%2C+MERCHANT+FIELDS&tnf=ZONES+RELATIVES+%C3%80+L%27ARTISTE%2C+AU+FABRICANT+OU+AU+MARCHAND&pID=1&pID1=1 so that could be associated with a particular object and where it was purchased. Here are the Merchant fields: https://app.pch.gc.ca/application/ddrcip-chindd/recherche-search.app?lang=en&qlang=en&dd=sh-hs&pID=1&sub=merchant&mne=&ac=false&rac=false For artists, though, I suspect that in this case, as in many of the elements the information will be buried in a bio free text field. I can easily think of use cases for an artist travelling and working in a location, but will come up with one where artists worked in the same location which was home for neither. |
Found an example; of course there are others. The artist Thomas Moran worked on a volume called "Picturesque Canada'. During this time he set up his studio in New York and worked out of the Booth buiding, which acted as a sort of artist centre for performing and visual artists, but before this, he and his brother travelled together to London in 1861 and studied William Turner's paintings. https://www.nga.gov/collection/artist-info.1730.html This artist has a lot of travel associated with his work (sometimes with other artists), but these are two instances of working with other artists who would have had intersecting sojourn dates. As I mentioned above, though this type of detail is likely to be found in full text bios or sometimes notes related to specific works of art. |
Thank you @scarey-chin for this examples! The Merchant Address field and the Merchant City would be the location of the group, although in CIDOC CRM the address is an appellation. I have modeled something in the CHIN:establishing, but it is not working like that.
As for the example of Thomas Moran, the question here is whether to model his travel in London as several move events from New York to London, then back from London to New York, or as a "sojourn" (still need to find a better term) in London for the duration of his stay.
|
Sojourn Name AlternativesIn terms of naming the patterns we could consider the following options: 1. Stay 2. (Actor) Location
3. Localisation
Con: It is not clearly related to an action so that the term is less consistent conceptually with the pattern, although less so than location in my opinion as localisation implies a state of being whereas location refers to a place). OpinionMy personal opinion is that localisation would be best. Then we would have to determine whether we find it necessary to specify Actor Localisation or if simply Localisation is sufficient (keeping in mind that there will eventually be an Objects facet to the TM and the "localisation" field for the objects will use a different pattern that will have to be named as well). If using localisation, I think it would be most consistent to use |
I feel like the scope note of F51 is to specific for what we are aiming to model:
I could be somewhere for many other reasons than professional and creative ones.
At first glance, I prefer the P7 option. P16 scope note seems again to specific for our purpose:
I don't feel like the name is essential to the activity of being somewhere.
In my opinion, our goal is not to identify the way to contact an actor, so going through a spatial pattern seems to be the best way of modelling the info.
After reading @KarineLeonardBrouillet's post, I feel like I prefer the "stay" option since it's not something already used in CIDOC CRM and it's oriented towards action like an activity should be. However, I'm not against "localization" and I don't think we have to add "actor" in front of it since objects won't be performing activities, so the distinction should be clear. |
After discussing this with CHIN's semantic committee, "stay" has been selected as the preferred term for this field mainly because it conveys the fact that it is a state of things rather than a description, thus better indicating the active part of the actor in the process. |
At the Semantic Committee meeting on 2020/11/03, we decided to go with the |
Summary of the decisions to add to the documentation:
|
1, 2 and 3 are done. 4 will require a new Entry Node for the |
As it is presented in the new v1.6 of the TM, there is 4 ways of rendering the geographical presence of
E39 Actor
:E9 Move
forE21 Person
E7 Activity
typed "Sojourn" forE21 Person
andE74 Group
E8 Acquisition
forE74 Group
CHIN:Establishing
forE74 Group
E9 Move
eventAs written above, the E9 move event is recommended in CIDOC CRM to document the change of location for the E19 Physical Object (including the E21 Person). It does not document the location of that person, but rather the event of moving from one place to the other. This model is therefore useful for documenting long travels, but counterintuitive and goes against the usual documentation of the place visited by an actor.
Sojourn
Another way of modeling the locations of
E39 Actor
is to have some kind of “sojourn” model. This means representing the stay of someone, rather than modeling its movements. It is not retrained to vacations or stay away for someone customary residence.E8 Acquisition
This use of
E8 Acquisition
could therefore document the location of aE74 Group
and its growth through time.In this modelization, the location where the
E74 Group
is established is anE22 Man-made Thing
, seen as the real estate property of the group. The title of property is then acquired by theE74 Group
through the propertyP22 transferred title to
and theE8 Acquisition
event and linked to the real estate through theP24 transferred title of
.We may need a loss of title in this pattern
CHIN:Establishing
George Bruseker proposed in one of the comment to create a new class, a CHIN:Establishing that would be the subclass of
E7 Activity
andE13 Attribute Assignment
. A new property, should also be created,CHIN:established at
, that would link theCHIN:Establishing
event with theE53 Place
.I am not sure how to model the address though.
We would also need a dis-establishment pattern
Questions
E21 Person
and theE74 Group
?-- In my opinion, the
E9 Move
pattern is the best for theE21 Person
as it follows CIDOC CRM logic, is easy to model and can document long travels. The problem is thatE9 Move
cannot be used forE74 Group
.-- The Sojourn pattern is not really satisfactory for me, as it does not render easily the location for
E21 Person
andE74 Group
, and does not follow CIDOC CRM logic. Nonetheless, the Sojourn pattern is closer to how museums usually record locations of actors.-- The
E9 Acquisition
pattern is quite suitable forE74 Group
but has a bit too narrow scope, as it is suitable only for the actually property of a place, not really just the occupation of a place (like a group of artists could occupy a shared atelier or meet and work in a coffee place).-- The Establishing pattern is similar to the acquisition one, but have a broader scope. The "problem" is that we have to create a class and property, which is what we wanted to avoid.
The text was updated successfully, but these errors were encountered: