Address the future of dct:relation with RDF link

[andrewbattista]

Thus far, we are not leveraging the dct:relation field in the application at all, and not everyone is using it anyways. As we've experimented with using the spatial search API on GeoNames to glean more placenames for the dct:spatial_coverage field, we've noticed some potential misfires. It could be a good idea to either figure out a way to leverage this field or omit it from the schema (or just let it be for now?

[karenmajewicz]

Since the field has been deprecated, is NYU still recording the RDF links anywhere? Also, were "misfires" mostly user error?

I have been looking into improving our Place Keyword normalization, and leveraging a GeoNames URI seems like a promising idea. Is this still being considered by anyone else?

[mejackreed]

We are using GeoNames for all of our placenames, just not storing it (the URI) within GeoBlacklight-Schema. That lives within our other MD records.

https://github.com/OpenGeoMetadata/edu.stanford.purl/blob/master/bf/355/hc/1305/mods.xml#L79 https://github.com/OpenGeoMetadata/edu.stanford.purl/blob/master/bf/355/hc/1305/iso19139.xml#L237-L273

[karenmajewicz]

Storing the GeoNames URI in the more comprehensive metadata file makes sense. We do use GeoNames for many of our GIS records for which we create ISO 19139 metadata files.

However, for the scanned maps, we have only been creating GeoBlacklight JSONs, since most of the metadata was already in Dublin Core.

[andrewbattista]

I think we preserved the URIs in the data that we had already collected but stopped adding them in subsequent record creations this past academic year. I'm going to add the Schema Changes label on this for now, but it's possible that if we're still OK with excluding URIs, we can close this issue