Discussion: Related Places

[kintopp]

I need to manually add some sample RDF data for St. Adalbert church in Opele. https://zabytek.pl/en/obiekty/opole-kosciol-parafialny-pw-matki-boskiej-bolesnej-i-sw-wojc

[kintopp]

Using WikiData, I've created a basic record for St. Adalbert in Opele based on a description of the church by the National Heritage Board of Poland.

https://www.wikidata.org/wiki/Special:EntityData/Q55338793.json https://www.wikidata.org/wiki/Special:EntityData/Q55338793.rdf https://www.wikidata.org/wiki/Special:EntityData/Q55338793.ttl

Would it be possible to use this as a starting point for the demo sample related place entry?

As an aside, WikiData's search & autocomplete feature is both powerful and limiting. It's easy to pick the 'wrong' property if it happens to appear higher in the results. I also couldn't understand why renovated/restored/repaired were all not available properties. I would have liked to have said something about when the facade was restored but couldn't find a way to do this.

[gklyne]

I'm confused. Did you create the wikidata record for Q55338793? If so, that's a lot of data to work through (7000 lines of Turtle). If not, where is the data that you created?

[kintopp]

Yes, I did. The human-readable version is here: https://www.wikidata.org/wiki/Q55338793 Please feel free just to copy manually from that for a sample related place entry. I was hoping (naively) that by creating the entry directly in WikiData, you'd also easily be able to process and reuse its RDF.

[gklyne]

Aha, that's more tractable! It appears that Wikidata adds a lot of supporting definitions and/or boilerplate in the RDF.

[kintopp]

An update from Graham, originally per email:

I've made an initial stab at some related place data:

https://github.com/culturesofknowledge/emplaces/blob/develop/models/20180726-St-Adalbert-example.ttl

Where it makes sense, I've stuck to the existing place data model; e.g.

rdfs:label rdfs:comment rdfs:isDefinedBy (not sure about this, but I think it's OK for now) rdfs:seeAlso em:canonicalURI em:alternateURI em:placeCategory (but using new value gn:S) em:placeType (using new value gn:S.CH) em:preferredName em:alternateName em:displayName em:where em:when em:hasRelation (using new relation type em:S_PART_OF_P) em:relatedResource

Also annotations for map resources (if available).

Then, for values that are specific to the related place type, I've used the web annotation structure with a different value for the motivation. And I've introduced resource descriptions for the annotation motivation values that can be used to define labels for display in the UI.

These new values can be seen from about line 190 onwards.

This is a slight change from what I originally had in mind, but when I got into the specifics, it seemed to me that whatever else I did would effectively be reinventing something like the annotation structure we're already using.

[gklyne]

This example may need updating to allow for some subtleties introduced by the proposal to handle multiple sources for core place information (issue #26).

[gklyne]

I've made some additions to the example data to clarify the role of type information, so the reference to line 190 in the quoted email above should now be read as about line 205.

I.e., look at about https://github.com/culturesofknowledge/emplaces/blob/develop/models/20180726-St-Adalbert-example.ttl#L205