List all persons and organizations

[rtroncy]

We will ultimately attempt to link all persons and organizations with URI from some authorities. One obvious candidate is for example ISNI (http://www.isni.org/search) which also offers a search API.

In order to find out what sources we should use, the first step is to list all authors and organizations using simple SPARQL queries.

[tschleider]

I created three queries, one for E39_Actor, one for E21_Person and one for E40_Legal_Body, which should cover all authors and organizations in the KG right now.

They look all like this. Results are above in the links for each class.

prefix crmdig: <http://www.ics.forth.gr/isl/CRMext/CRMdig.rdfs/>
prefix crmsci: <http://www.ics.forth.gr/isl/CRMsci/>
SELECT DISTINCT ?actor ?label
WHERE {

    ?actor a ecrm:E39_Actor .
    ?actor rdfs:label ?label .

}  

[rtroncy]

Thanks, those results are interesting and reveal a few problems:

• When are we creating instances of ecrm:E21_Person? It seems that this is when the records mention a right holder. However, http://data.silknow.org/person/cb35b2cd-f3a6-34b4-9fbe-3870692d533a and http://data.silknow.org/person/e0d25d5c-9d7e-33ed-ad38-8b960d697f98 are obviously the same person. Similarly, http://data.silknow.org/person/8a6e44da-bac1-384c-b670-14d91bf14142 and http://data.silknow.org/person/45cf9c47-c355-3abf-9067-2abe54436dff are probably the same person. http://data.silknow.org/person/f01bbaab-3633-3630-8ef1-0609039a2d9d is 2 persons and not a single one.
• When are we creating instances of ecrm:E39_Actor? This list seems to mix persons and organizations (e.g. empresa xxx). We should list the role those actors had. I quickly saw: maker, artist, author
• When are we creating instances of ecrm:E40_Lega_Body? Looking at the values reveal clear bugs, such as considering that the comma is a separator while it is not, e.g. in https://data.silknow.org/organization/8541847f-780e-3bce-8688-a882f0e2589b. It seems that we create those instances for various reasons such as: ecrm:P75_possesses, ecrm:P29_custody_received_by, ecrm:P129_is_about

[rtroncy]

The decision is to always rdf:type these entities as ecrm:E39_Actor.

In addition, when we know it for sure, we should add the type ecrm:E21_Person (when this is an individual) or ecrm:E40_Lega_Body (when this is an organization) in a multi type fashion. It is acknowledged that in the majority of cases we will NOT know for sure so the entity will just have the E39 type.

Consequently, I have modified the URI Patterns guidelines so that we only use one pattern: /actor.

/ cc @tschleider

[rtroncy]

This issue is now a priority one. There are a number of things to do:

• change the modeling and corresponding URI pattern for the entities of type E39, E21 and E40;
• change the way the UUID is generated, e.g. using firstName and lastName so that obvious duplicates get naturally merged (we do not create 2 different URIs for the same person). Pay attention that one URI composed from the hardcoded actor 'anonym/anonym' may have multiple occurrences.
• attempt to reconcile duplicates within the SILKNOW dataset
• interlink the person names with ISNI, Wikidata and possibly other sources using their search API or reconciliation services.

For the last item, watch the Reconciliation API and consider the OpenRefine reconciliation API to Wikidata

[rtroncy]

See also this nice table prepared by @mpuren which indicates for each museum source, the potential role that the ecrm:E39_Actor will play: author, maker, designer, former owner.

We should also decide how we want to represent this information if it is worth it.

[pasqLisena]

All given examples of duplicates are not valid anymore. It is not clear if this is due to a previous fix (as it appears), or not.
From what I see, no action is required for the 2nd task.