Mint/Link Parks and Other Places Without Postal Codes

[dlh28]

How should Artsdata handle open air event venues that do not have a postal code?

For example, ATB Mainstage is a permanent stage in Prince’s Island Park in Calgary that hosts Calgary Folkfest, along with concerts by Calgary Philharmonic and other presenters. On the City of Calgary website, Prince's Island Park is given an intersection as an address (4th St and 1st Ave SW), without a postal code. No postal code could be found other than the one automatically generated by OpenStreetMap.

@GaryMan1968 have you run into similar issues with powwow grounds or other venues not having a postal code?

@fjjulien, @saumier, @MorganPann and I briefly discussed this issue during a biweekly meeting and decided to bring it to GitHub for further discussion.

[fjjulien]

I was trying to reconcile the Confederation Park (https://nac-cna.ca/venue/confederation-park#Place) in the NAC dataset and I ran into this problem. This data record had no address whatsoever and could not be minted from the NAC dataset. I therefore turned to Wikidata to retrieve the item for the Confederation Park (Q4345230) and to mint an Artsdata ID for it using the "Mint using Wikidata" feature.

Here are the steps that I took to make this Wikidata as compliant as possible with Artsdata's requirements:

• I added the type "open-air event venue" to meet the requirement that the place entity be a subclass of "event venue".
• I added a street address, describing the intersection of the two main ways by which the park is located, thereby meeting the SHACL requirement to provide a streetAddress.
• The statement "located in the administrative territorial entity was present, which meets the SCHACL requirements to provide a addressLocality and addressRegion.
• I could not find an official postal code for this park. Rather than using Google's postal code, which I could not validate from another source, I left it blank.

Unexpected outcome

I was able to mint a new Artsdata ID for this Place, even though it did not satisfy SHACL validation.

Here is the resulting Artsdata record: http://kg.artsdata.ca/resource/K2-7263

However, when I attempted to refresh this Place from Wikidata, the refresh workflow failed because of the missing postal code.

As a result, the NAC record for the Confederation Park cannot be linked to this newly minted Artsdata record, because it does not have a name nor a postal code. This is problem for the 2627-W-011 NAC Implementation Review project because the event located in this park cannot be minted an Artsdata. The same issue will occur in other NAC places without postal codes.

[fjjulien]

Related discussion: Place: how to manage event locations without a full postal address #126

[fjjulien]

Solutions to explore

Introduce an exception for open-air event venues

Could we add a SHACL exception to accept a Place without a postal code, when the entity has the type or additionalType adr:OpenAirEventVenue or wd:Q117187730 (or subtype of)?

We should also consider extending this exception to the streetAddress property, because many festival sites do not have a street address.

This would be good opportunity to start using the Artsdata Place Controlled Vocabulary.

Accept either a postal code or geographic coordinates

In the absence of a postal code, a park of festival site should be described with geocoordinates. Otherwise, there's no way for human users to get an itinerary to these places. We could propose to data providers that they populate the latitude and longitude of their open-air places, and they would be receptive to this suggestion. As to parks in Wikidata, it's very easy to fill in the geo coordinates.

[fjjulien]

@saumier This is out of scope for the NAC project. Do you want me to create an open work order for modelling work, or do you prefer including this into 2627-W-006 Update SHACL Library?

[saumier]

@fjjulien Please create an open work order for modelling work. My instinct is telling me that we are going to work on the Artsdata model quite a bit.

[fjjulien]

@saumier Done: 2627-W-014 Open Data Modelling WO

[fjjulien]

This issue was discussed with @troughc and @saumier in a meeting today.

• Caitlin thinks we should accept geo coordinates in place of a postal code.
• Gregory thinks we should require both an additionalType and a postal code. The postal code is really helpful to compare data records. Geo coordinates aren’t. We would need to define a radius for the match.

[fjjulien]

I think it makes sense to require both an additionalType and geocoordinates when minting a Place from Wikidata: the instance of wd:Q117187730 value would be already present and geocoordinates are easy to add prior to minting.

However, for JSON-LD data providers, I believe it would place too high a compliance burden upon them. We will still be regularly blocked, unable to mint an Artsdata ID for a Place record (and for the associated events).

[saumier]

To mint a place I propose the following:

1. complete schema:PostalAddress (including streetAddress, locality (city), region (province), country, postalCode)
   OR
2. schema:longitude, schema:latitude AND schema:PostalAddress with region (province) and country
   OR
3. schema:geo with a GeoShape AND schema:PostalAddress with region (province) and country

The schema:PostalAddress with province and country is easy to meet for any data provider. It also servers as a "check" that grounds the geo-coordinates incase the data provider gets them backwards or makes a mistake.

Place type is good to have but remains optional. It is an Artsdata controlled vocabulary that is not (yet) widely adopted. When minting from Wikidata, the place type would be mapped from the Wikidata P31. But place type would remain outside of the requirements to mint a place.

For more details see my other discussion:
#126 (comment)

[saumier]

@troughc @MorganPann @fjjulien Please weigh in to this proposed solution. If you support it please "thumbs up" and/or click the up arrow. If you have a different proposal please add it to the discussion. Please respond either way in the next 24 hrs. Thx.

[fjjulien]

I am supportive of the proposal.

I like the fact that you do not place the requirement of an addressLocality in scenarios 2 and 3. This will remove a barrier for festivals and powwows that are held outside of urban settlements.

Note to self: In documentation pages, we should make it very clear that a "complete schema:PostalAddress" includes a postal code.

[saumier]

Work on implementing this solution is being tracked with issue:

• https://github.com/culturecreates/artsdata-api/issues/137

[fjjulien]

Many documentation pages will require updating after this change is implemented. I created an Asana task to help coordinate the work between Morgan and I.

This issue should not be closed until all documentation pages have been updated.

[saumier]

@fjjulien Yesterday I changed your initial Github issue into a Github discussion so we could document the process.

I know we don't have a strict process, but before committing to my proposal I'd like to get some consensus. Is there consensus on my proposal? I'd like at least 4 of us to agree with the direction. Maybe @troughc @MorganPann @saumier and @fjjulien could reply or "Thumbs up" or else propose other ideas.

I'd wait another day and then if we have consensus you or I can click "mark as answer" (and add the new "Verified answer" badge which would be cool).

Once the answer is marked, we should start the work. You already created Asana tasks. I will create Github issues linked to this discussion. The Github issues will get closed once each is completed. Your team can advance with tasks in Asana in parallel. But I really want to conclude this discussion first with an answer before proceeding to do the work.