InTaVia / idm-rdf

Intavia Data Model for RDF data
1 stars 2 forks source link

How to include residence data? #9

Closed CarlaVS closed 1 year ago

CarlaVS commented 2 years ago

Victor (BiographyNet data): What to do for other relations (residence)?

I think that depends on the exact data. The first idea would be to use E9 Move, but it just makes sense when we know something about the Moving Events. Then there is the property “P74 has current or former residence”, I didn’t include that because I saw no way to temporalize it.

Are there any suggestions or opinions for that problem?

razz0 commented 2 years ago

One approach would be to use the generic E7 Activity to represent an actor being at a certain place at a certain time. The definition of E7 Activity is quite encompassing and while we probably won't know from data what an actor is doing at certain place, one could assume that the actor is doing something.

The vagueness of E7 Activity is well conveyed in this example from CIDOC CRM 7.1.1 definition:

Kira Weber working in glass art from 1984 to 1993

In a similar vein one could express "Person X residing in London in 1876" as activity (especially with the assumption that the person is actually doing something there). If necessary, this could be made even more vague by relating the person to the activity with one of the superproperties of "P14 carried out by" (either "P11 had participant" or "P12 occurred in the presence of"). This could be understood as, e.g. "Something happening in London in 1876, which (physically) involves Person X".

This approach could also be applied to E74 Groups if necessary, which (unlike E21 Persons) are not physical objects and for which thus the E9 Move is not valid.

For general reference, here is a quote about residence from the CRM definition (which is not very helpful because of the lack of temporality in P74):

Actor Locations: Tracking the history of the location of actors is related to the history of object location with a significant difference: in the CIDOC CRM an actor is defined as an entity featuring agency which is not the case in objects and physical entities in general. Not being physical, an actor cannot be the subject of an instance of E9 Move which documents physical relocations. The CIDOC CRM thus offers the notion of P74 has current or former residence in order to document the relation of a person or group to a location as residing there at some time.

CarlaVS commented 2 years ago

I would propose to solve it with E7 / event role from biocrm and a matching event role. Thank you!

biktorrr commented 2 years ago

So, I have six types of such "activities" (in original source called "states"): Occupation, Education, Residence, Religion/Faith, ClaimToFame. All include potentially temporal and spatial qualifications (to/from/where).

For Occupation, we use bioc:has_occupation triple with an instance of bioc:Occupation as object, but that only works for non-qualified information. So, I also add on top of that:

For the non-occupation activities, I now use bgn:has_residence etc with the same construct.

So I can use E7_Activity instead of E54_Event, and still use the bearer_of, for the "complex part" but what do I use instead of the bioc:has_occupation?

yoge1 commented 2 years ago

Just to clarify:

For non-occupation activities, I think we could manage without having a simple shorthand property (so not to have a structure similar to bioc:has_occupation for occupations; the residency would be modeled in any case using a specific bioc:Actor_Role, e.g. idm:Residency), but if we wish to have a shorthand property we could maybe use bgn:has_residence (but I'm not sure what its range is; maybe not suited for having a bioc:Actor_Role instance as object?), or come up with a new property in the idm namespace (or if we think that it's generic enough, include it in the bioc namespace).

sennierer commented 1 year ago

@biktorrr and @yoge1 can we close this issue or is there still something to be discussed?

biktorrr commented 1 year ago

I think so

sennierer commented 1 year ago

ok, thx....closing that for now