Artist's location

[saumier]

Users of data in Artsdata would like a consistent property to know the location of an Artist (dbo:Agent).

Wikidata	instances Human (Q5)	instances Organizations	comment	related schema.org
work location (P937)	489,560	374	Preferred in CAPACOA uploads to Wikidata	workLocation
residence (P551)	353,619	N/A	frequently used on items manually populated by Wikidata users	homeLocation
headquarters location (P159)	N/A	65,699	Some organizations
located in the administrative territorial entity (P131)	N/A	too many timeout	the most commonly used property by far
location of formation (P740)	N/A	24,812	Common property for musical groups	foundingLocation

How should Artsdata map various techniques used in Wikidata to a consistent property in Artsdata?

[saumier]

Given that Artists includes the group of individual people and organizations (groups, bands, theatre troupes, etc.), I propose that Artsdata use https://schema.org/workLocation for individual people and https://schema.org/location for organizations including musical groups.

Then the mapping from Wikidata to Artsdata:

Wikidata	Mapped in Artsdata
work location (P937) or if none then use residence (P551)	https://schema.org/workLocation
located in the administrative territorial entity (P131) or if none then use location of formation (P740)	https://schema.org/location

In addition, Artsdata would add to the linked Place URI a schema:PostalAddress with schema:addressCountry label and, if in Canada, the schema:addressRegion province label.

[fjjulien]

@saumier schema:workLocation makes absolute sense for individual artists.

For informal groups whose provenance is documented with location of formation (P740), we should map to schema:foundingLocation. These two properties are deemed equivalent in Wikidata.

I am concerned about using schema:location for formal organizations:

1. I'm not keen about using schema:location for both Event and Organization entities, because this has been the cause of improper modelling in Wikidata batch uploads (contributors sometimes use "wdt:P276 (location) in place of wdt:P131). Of course, we know better and we haven't made this mistake so far in our batch uploads from Artsdata to Wikidata. So that's not my main concern. My main concern is what follows.
2. When we ETL member data from CAPACOA and Scène Pro, we map the relationship between an Organization and a Place to schema:location (see this example from CAPACOA and this example from Scène Pro). This means the same kind of geographic information would be modelled with two distinct properties (address and location); and the same schema:location property would be used to denote either a relationship to a venue or the location of the head office of the organization. Messy.

Using the same property to describe two distinct relationships would be dangerous. Even though we can ensure to pass on the right value to ATC (by retrieving the location from an Artsdata-minted entity), confusion would be bound to arise sooner or later within the Artsdata community.

Using schema:address for formal organizations could be a solution... Depending on how you intend to model the range in Artsdata...

If I understand you right, your intended range for either Schema property would be a nested Place type entity (for example, a city or a province, depending on the granularity of the data in Wikidata) with a URI identifying the Place. Then this Place, would have a schema:address with a nested PostalAdress object. Is this correct?

If so, then schema:address is not a good alternative to schema:location because the expected value for schema:address is a PostalAddress type entity, not a Place.

The only other candidate Schema property for formal organizations is schema:foundingLocation (as I suggested for music bands). This statement would be true in >95% of cases, but could be false in others.

A final idea: Could we simply reuse wdt:P131 for formal organizations?

[saumier]

Following our discussion today:
s:Person --> s:workLocation --> s:Place --> s:address --> s:PostalAddress for individual people.
s:Organization --> schema:location --> s:Place --> s:address --> s:PostalAddress for organizations including groups

[saumier]

Now for the mapping from Wikidata to Artsdasta...
For People: Map wikidata's "work location" and if empty use "residence" to fill in schema:workLocation's schema:Place --> schema:PostalAddress.
For Organizations/Groups: Map Wikidata's "headquarters location" and if empty use "location of formation" and if empty then "located in the administrative territorial entity" to fill in schema:location's schema:PostalAddress.

[saumier]

@fjjulien I looked at the data in Artsdata regarding the range for schema:location. In Artsdata the range of schema:location is always schema:Place or schema:Role (for qualifying the relationship of the entity to the Place). So I updated the solution for ATC above such that both s:Person and s:Organization link to s:Place.

[saumier]

@fjjulien Another idea is to use a sub-type of s:Place like s:State which is for a province or territory. The @id could be the Wikidata URI for Canadian provinces like http://www.wikidata.org/entity/Q1904 for Ontario. The question is how to extract province and country from the data using a frame and without knowing in advance.
s:Person --> s:workLocation --> s:State
s:Organization --> s:location --> s:State

[MaudeFJ]

Petite note à titre informatif, de mon côté j'ai déjà ajouté ce champ dans mon CMS, donc les artistes quand ils rentrent leurs fiches sont invités à le compléter. J'avais d'abord mis "lieux de travail" comme nom du champ, et c'est peut-être un enjeu seulement lavallois, mais beaucoup d'artistes vivent à Laval, mais travaillent principalement à Montréal, donc ça créait de la confusion au moment de remplir le champ, j’ai donc changé pour Ville de résidence.
(Je sais que vous travaillez plutôt de l'autre côté de la donnée, une fois qu’elle est déjà là comment on la schématise, mais ça peut peut-être être intéressant pour vous de garder ça en tête en ce qui a trait à la collecte de données)