Skip to content
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

Open
stephenhart8 opened this issue Nov 13, 2019 · 25 comments
Assignees
Labels
modeling This issue concerns how we organize the information semantically Update Documentation Improvements or additions to documentation use cases needed This issue needs more use cases to be resolved

Comments

@stephenhart8
Copy link
Collaborator

stephenhart8 commented Nov 13, 2019

As it is presented in the new v1.6 of the TM, there is 4 ways of rendering the geographical presence of E39 Actor:

  1. With the E9 Move for E21 Person
  2. With the E7 Activity typed "Sojourn" for E21 Person and E74 Group
  3. With the E8 Acquisition for E74 Group
  4. With the CHIN:Establishing for E74 Group

E9 Move event

As 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.

Address and moving

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.

Sejour

E8 Acquisition

This use of E8 Acquisition could therefore document the location of a E74 Group and its growth through time.
In this modelization, the location where the E74 Group is established is an E22 Man-made Thing, seen as the real estate property of the group. The title of property is then acquired by the E74 Group through the property P22 transferred title to and the E8 Acquisition event and linked to the real estate through the P24 transferred title of.

Real_Estate_Aquisition_Group

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 and E13 Attribute Assignment. A new property, should also be created, CHIN:established at, that would link the CHIN:Establishing event with the E53 Place.
I am not sure how to model the address though.

Establishing

We would also need a dis-establishment pattern

Questions

  • Are the models above seems right for you?
  • Which pattern seems more suitable for the E21 Person and the E74 Group?
    -- In my opinion, the E9 Move pattern is the best for the E21 Person as it follows CIDOC CRM logic, is easy to model and can document long travels. The problem is that E9 Move cannot be used for E74 Group.
    -- The Sojourn pattern is not really satisfactory for me, as it does not render easily the location for E21 Person and E74 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 for E74 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.
@stephenhart8 stephenhart8 added the modeling This issue concerns how we organize the information semantically label Nov 13, 2019
@stephenhart8
Copy link
Collaborator Author

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.

@KarineLeonardBrouillet
Copy link
Collaborator

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 E9 Acquisition for sure as groups often stay in places without having any official claims to them, sometimes even intentionally so (e.g. squatting), as do persons for that matter.

@illip
Copy link
Collaborator

illip commented Nov 24, 2019

At first glance, I would vote for E9 Move and E9 Acquisition patterns to avoid creating something new.

I know that E9 Move might be counterintuitive for museums, but I prefer to document active activities than the passives ones.

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 E7 Activity -> P2 has type -> E55 Type (Move 2!). That way we can move any kind of Actors ;)

@stephenhart8
Copy link
Collaborator Author

stephenhart8 commented Nov 26, 2019

Indeed, the E9 Move is strictly linked to E21 Person, and not to E74 Group.
@illip your idea of Move2 is exactly the Sojourn pattern, that we imagined to encompass the movements (or stay in the case of Sojourn) of every E39 Actor.

The acquisition pattern is good enough for companies that owns buildings, but could we use the E8 Acquisition if a group is just renting a place? Or that multiple artists groups share the same building?

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 E8 Acquisition pattern is no adequate.

To summaries my opinion:

  • I would go for the E9 Move pattern for E21 Person,
  • If we want to be more flexible about the location of groups, use a created Chin:establishing pattern, and if we are ok by only documented groups that officially owns a location, then use the E8 Acquisition pattern,
  • I would avoid using a "move2" or "sojourn" patterns, as it seems to me as a bad use of CIDOC

@Habennin
Copy link

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?

@stephenhart8 stephenhart8 added the use cases needed This issue needs more use cases to be resolved label Nov 29, 2019
@stephenhart8 stephenhart8 removed the F2F label Jan 8, 2020
@Habennin
Copy link

Just to keep this ball rolling...

What are the real world situations?

  1. Someone lives somewhere (they have residence there)
  2. Someone visits somewhere (they travel there then they leave)
  3. Some group is based somewhere (they have a base of operation at a place)
  4. Some group establishes itself in another place ie in real life also and not just CRM groups don't move. Sears doesn't 'move' to Winnipeg, because Sears has no body. Sears as a corporate entity, a legal actor in the western sense, opens a store thus establishing itself in another place.

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.

@KarineLeonardBrouillet
Copy link
Collaborator

Notes on verbal meeting held 2020-02-17:

Maybe could be reduced to two patterns because:
Either you want to know that a person went from a-b-c so you need to know locations, people, and time between those things.

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.

@VladimirAlexiev
Copy link

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

@illip
Copy link
Collaborator

illip commented Mar 16, 2020

@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 E9_Move for person trajectories and E7_Activity (Sojourn) for actors places of activities. From my understanding it would be enough to start, unless we have to represent the specific places where the groups were taking their decisions. If so we would need a CHIN:Establising pattern if we don't want to manage everything in E7_Activity (Sojourn).

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?

@VladimirAlexiev
Copy link

VladimirAlexiev commented Mar 26, 2020

Ok, so it's like "floruit" but for Groups. You guys should use:

frbroo:F51_Pursuit "periods of continuous activity of an Actor in a specific professional or creative domain or field".

Examples:

  • Natalya Goncharova working as a set and costume designer, painter, illustrator and poet in Russia and France in the first half of the 20th century
  • Satyajit Ray working as a filmmaker, writer, composer and graphic designer in India in the second half of the 20th century
  • Folger Shakespeare Library in Washington studying the works of William Shakespeare
  • M. & N. Hanhart working in lithographic publishing (1839-1882)

Properties (in addition to place/timespan inherited from E7_Activity):

  • R59 had typical subject (was typical subject of): E1 CRM Entity
  • R60 used to use language (was language used by): E56 Language

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 frbroo:F51_Pursuit.


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).
If you mean it for "floruit" then also use F51_Pursuit.


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 E7_Activity.P2_has_type when appropriate.

@stephenhart8
Copy link
Collaborator Author

stephenhart8 commented Mar 30, 2020

Establishing for Groups

@VladimirAlexiev The idea for this pattern is to document the geographical location of Actors. That means the physical location for E21 Person (where the person is) and the presence of E74 Group(this group has some stores in those locations).

To clarify this, two simple examples:

  • Person: Jean Paul Riopelle was born in Montreal, and moved to Paris in 1947 and lived there for a year before coming back to Montreal.
  • Group: The Example Company, a shoe company founded in 1988, open its first store in Montreal and a factory in Québec in 1989, then a second store in Ottawa in 1990 and a third in 1995 in Toronto but that one had to close in 1996.

With those two examples, we need to document the E53 Place, but also some information about this location, especially the dates where the actor is present.

The F51 Pursuit is an interesting proposition, but would not allow us to have the level of detail needed. We can add some locations to that event, but the dates associated with that F51 Pursuit would be the ones associated with the activity of the company, not the dates of the locations.
That is why I have proposed this "Establishing" event. This represents more the event of a group having some sort of geographical grounding, rather than the activity itself.
I hope that makes it a bit clearer.

We could use multiple F51 Pursuit, one for each location, but maybe that would be confusing?


Sojourn for Persons

The 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 E21 Person in a geographical location, rather than documenting the movement.
In the case of Jean Paul Riopelle, instead of having two E9 Move event Montreal>Paris and Paris>Montreal, we would have 3 locations associated with Jean Paul Riopelle: Montreal from his birth to 1947, Paris from 1947 to 1948 and then Montreal from 1948.
This proposition comes from the fact that most museums document the geographical location of actors that way, and not by moving event.

We need to rename this type of Activity.


Types of Activities

Thank you very much @VladimirAlexiev for this Events by Type, it is indeed very useful for our E7 Activity P2 has type

@VladimirAlexiev
Copy link

@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 location: use that when you don't have more specific info.

I agree that capturing the periods is more useful than recording a bunch of Moves (which are bound to be incomplete).

@Habennin
Copy link

Habennin commented Apr 4, 2020

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/

@stephenhart8 stephenhart8 changed the title Issue #31 - Move, Sojourn, Acquisition, Establishing: how to model the geographical presence of Actors? Move, Sojourn, Acquisition, Establishing: how to model the geographical presence of Actors? Apr 6, 2020
@VladimirAlexiev
Copy link

@Habennin One is not completely free to create whatever custom classes and props.

  • The Intro to the CRM describes what are CRM-compatible extensions: whenever possible, one has to create sub-classes, sub-props, or long-paths that elaborate existing props.
  • Sub-classes should be created only when they have specific props. (Though often this has been done in a "self-fulfilling prophecy" kind of way: by creating specific sub-props where the original prop would serve as well)
  • CRMbase was supposed to have those "master" super-classes and super-props: http://www.cidoc-crm.org/crmsoc/Issue/ID-358-crmsoc-and-scope-of-crm-modules discusses relaxations where extensions can introduce new super-classes and super-props to reduce the complexity of CRMbase, but as minimal as posisble
  • http://www.cidoc-crm.org/crmsoc/Issue/ID-469-a-phrase-of-every-property-of-every-extension has a list of the super-classes and super-props (or lack thereof) in extensions

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:

@illip
Copy link
Collaborator

illip commented May 11, 2020

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 chin:Establishing, I think we don't necessarily need to this new class because the growth and decline of Sears can be handle with the Sojourn pattern because E74_Group can carry out an E7_Activity. It would then be possible to study the growth and decline of a company by identifying its different locations through time. To consider (@stephenhart8):

  1. We should probably find another name than "Sojourn" which is not enough inclusive for our needs.
  2. We might need to use a metatype pattern to be able to distinguish "Establishing" from other types of "Sojourn" Activities.

@Habennin What do you think?

@illip illip added Semantic Committee Issues to be discussed in an upcoming Semantic Committee meeting and removed next version labels Jul 6, 2020
@scarey-chin
Copy link

scarey-chin commented Jul 9, 2020

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?

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.

@scarey-chin
Copy link

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.

@stephenhart8
Copy link
Collaborator Author

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.

  • We will need to find a way to document the physical addresses of actors

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.

  • This issue will be discussed by the semantic committee and a decision will be taken in the following months.

  • In the mean time, it has been decided on the meeting of the 4th of August to only use the "sojourn" pattern in our internal tests of the model and the pipeline.

@stephenhart8
Copy link
Collaborator Author

From the fruitful discussions with the Semantic Committee on the 2nd of September, it seems that the privileged option to render physical location is to use an event that is typed as “sojourn” (the label of this Type is still to be changed, as “sojourn” is not satisfactory since it implies travel and we want the pattern to apply to all kinds of stays).
It is yet to be determined if that event should be an E7 Activity or a F51 Pursuit. F51 Pursuit is directly linked to the occupation of an Actor, but the aim of our pattern is also to render physical locations of actors that could not be linked to any occupation (like personal address).

It is also important to note that we have not yet decided if there will be only this “sojourn” pattern for geographical position in our model or also other patterns, like the E9 move.

More importantly, this meeting revealed the need for documenting the alternative names of an actor at the time of the documented location, especially for groups that could have multiple names at the same time. For example, the Wm. Notman & Son company had different names over time (Wm. Notman & Son Ltd, Wm. Notman & Son Regd), and it is important to link the addresses where the company was to the name it had at the time.

This could be done two ways:

  • By writing some algorithms that could link the dates of the different addresses to the dates of use of the different names of the company. This would nonetheless require to have the temporal data, something that is often missing from museum records. Moreover, if a company bears two different names at the same time, it would be impossible with an algorithm to know which one was used for the location.
  • By linking the E53 Place to the E41 Appellation through a property. The one that seems the best suited is P16 used specific object. The range of this property is E70 Thing.
    It seems to me that the second option seems the best.
    Here is a quick diagram with the example of the Wm. Notman & Son company (the appellation pattern is simplified here for lisibility purposes):
    Exemple_Notman_2-2

One other option is to link the F52 Name use activity to the E53 Place with the property p7 took place at
Exemple_Notman_3

Questions

  • Is the class F51 Pursuit of any use in the “sojourn” pattern? Or is it best to use the broader E7 Activity?
  • Which option is better: with P16 used specific object or the P7 took place at between F52 Name use Activity and the E53 Place? It seems that it is both technologically similar, but semantically different. What seems closer to reality?
  • Are there other ways of linking the place and the appellation?
  • I’ve also tried to model the physical address of the actor by using an E53 Place, that as the appellation the address, and that falls within the city. Is that the proper way of linking the address to the sojourn activity? The property P76 has contact point is of no use here.
  • What term, other than “sojourn” could be used in this pattern? It needs to render the physical location of an actor, either for work or leisure, in an owned property or in a public place, either temporary or for a longer period, and as a principal or secondary residency. “Physical presence” is an easy way to go. Any other ideas?

@KarineLeonardBrouillet
Copy link
Collaborator

Sojourn Name Alternatives

In terms of naming the patterns we could consider the following options:

1. Stay
Pro: It is an "action" concept/active verb, which makes the term conceptually consistent with the pattern.
Con: It might be less closely aligned with the actions of groups conceptually as well as less intuitive in such cases.

2. (Actor) Location
Pro: It is broad enough to cover our use cases (i.e. both individuals and groups).
Cons:

  • It is not clearly related to an action so that the term is less consistent conceptually with the pattern and does not intuitively refer to the fact that such locations involve both a time and place.
  • Location is used elsewhere in the Target Model for other purposes (Archival Document Location) so that it might lead to confusion. We would have to use Actor Location and Archival Document Location.

3. Localisation
Pros:

  • It clearly alludes to being somewhere at a specific moment
  • It is broad enough to cover our use cases (i.e. both individuals and groups) without being counter-intuitive for either of them.

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).

Opinion

My 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 P7 took place at as both the property and the name imply situating a time and a place.

@illip
Copy link
Collaborator

illip commented Sep 25, 2020

Is the class F51 Pursuit of any use in the “sojourn” pattern? Or is it best to use the broader E7 Activity?

I feel like the scope note of F51 is to specific for what we are aiming to model:

This class comprises periods of continuous activity of an Actor in a specific professional or
creative domain or field.

I could be somewhere for many other reasons than professional and creative ones.

Which option is better: with P16 used specific object or the P7 took place at between F52 Name use Activity and the E53 Place? It seems that it is both technologically similar, but semantically different. What seems closer to reality?

At first glance, I prefer the P7 option. P16 scope note seems again to specific for our purpose:

This property describes the use of material or immaterial things in a way essential to the performance or the outcome of an E7 Activity.

I don't feel like the name is essential to the activity of being somewhere.

I’ve also tried to model the physical address of the actor by using an E53 Place, that as the appellation the address, and that falls within the city. Is that the proper way of linking the address to the sojourn activity? The property P76 has contact point is of no use here.

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.

What term, other than “sojourn” could be used in this pattern? It needs to render the physical location of an actor, either for work or leisure, in an owned property or in a public place, either temporary or for a longer period, and as a principal or secondary residency. “Physical presence” is an easy way to go. Any other ideas?

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.

@KarineLeonardBrouillet
Copy link
Collaborator

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.

@illip
Copy link
Collaborator

illip commented Nov 18, 2020

At the Semantic Committee meeting on 2020/11/03, we decided to go with the p16_used_specific_object pattern to link the name of an Actor during a "Stay" event.

@illip illip added Update Documentation Improvements or additions to documentation and removed Internal meeting Semantic Committee Issues to be discussed in an upcoming Semantic Committee meeting labels Nov 18, 2020
@illip illip moved this from To do to In progress in Version 2.2 (August 2021) Dec 14, 2020
@illip
Copy link
Collaborator

illip commented Dec 17, 2020

Summary of the decisions to add to the documentation:

  1. We will remove all the other pattern options and keep only the Stay one.
  2. We will refer to this issue to keep a reference to the other patterns.
  3. We will remove all the "Sojourn" mentions and replace them with "Stay".
  4. We will enhance the pattern with the appellation path.

@illip
Copy link
Collaborator

illip commented Dec 22, 2020

1, 2 and 3 are done.

4 will require a new Entry Node for the E41_Appellation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
modeling This issue concerns how we organize the information semantically Update Documentation Improvements or additions to documentation use cases needed This issue needs more use cases to be resolved
Projects
Development

No branches or pull requests

6 participants