Resolve or document metadata range problems

[mjgiarlo]

From @hackmastera on June 4, 2015 18:21

This ticket is to open discussion.

In some cases, sufia creates properties on generic file which use predicates with ranges. When sufia uses strings as values it is not always conforming to the predicates as specified. We may wish to fix this situation by implimenting a way for the predicate to respect the specified range, or by changing the predicate for a given property. Where that would be as simple as switching from dcterms to dc-elements, I'll indicate on the list.

The following properties in sufia use predicates that have specified ranges*:

• resource_type, predicate: ::RDF::DC.type, range: "rdfs:Class" -- can change to DC11
• creator, predicate: ::RDF::DC.creator, range: "dc:Agent" -- can change to DC11
• contributor, predicate: ::RDF::DC.contributor, range: "dc:Agent" -- can change to DC11
• rights, predicate: ::RDF::DC.rights, range: "dc:RightsStatement" -- can change to DC11
• publisher, predicate: ::RDF::DC.publisher, range: "dc:Agent" -- can change to DC11
• language, predicate: ::RDF::DC.language, range: "dc:LinguisticSystem" -- can change to DC11
• based_near, predicate: ::RDF::FOAF.based_near, range: "http://xmlns.com/foaf/spec/#term_SpatialThing"
• related_url, predicate: ::RDF::RDFS.seeAlso, range: "rdfs:Resource"

the following additional proprties have skos:note "(This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/). As of December 2007, the DCMI Usage Board is seeking a way to express this intention with a formal range declaration." We may wish to discuss whether any of these are therefore misleading, as well.

• part_of, predicate: ::RDF::DC.isPartOf
• tag, predicate: ::RDF::DC.relation -- can change to DC11
• subject, predicate: ::RDF::DC.subject -- can change to DC11
• source, predicate: ::RDF::DC.source -- can change to DC11

*(other than rdfs:literal, xds:string, which I believe are okay to put strings in)

Copied from original issue: projecthydra/sufia#1179

[mjgiarlo]

From @tpendragon on June 4, 2015 18:32

related_url should be fine, a literal is an rdfs:Resource, and a string is a literal under RDF 1.1. (An RDFS::Resource is "All things described by RDF"

based_near looks particularly problematic.

[mjgiarlo]

Re: based_near, strings are currently stored because we lacked then a common pattern to store URIs and display labels. I am given to believe that we're much closer to a pattern now, so the timing is good to revisit this decision.

FWIW, labels in this field should be coming straight out of one of the Geonames APIs, so we could theoretically define a migration path that hits the APIs and matches up string labels with URIs.