 |
 |
I don't recommend using different properties that have the same basic semantic meaning for those different contexts (dc:subject vs. dcterms:subject). In a linked data environment, I don't recommend using Dublin Core Elements at all, but only dcterms. It is possible to harvest subject terms regardless of whether it is a literal or a URI, but the harvester might have to take some additional action to generate a human readable result from an LCSH URI. 1. The harvester goes out and fetches the machine readable data for http://id.loc.gov/authorities/subjects/sh85002782 to get the label 2. You import the RDF for LCSH into your system so that an OPTIONAL line can be inserted into SPARQL (assuming you are using SPARQL) to get the skos:prefLabel for the URI directly from your own system. I'd suggest discussing these options with developers that may potentially harvest your data, or at least provide a means to developers to give you feedback so that you can deliver a web service that makes harvesting as efficient as possible. I hope this is useful. I think there are many possible solutions. But, in sum, don't use dc:subject and dcterms:subject simultaneously. Ethan On Mon, May 9, 2016 at 1:58 PM, English, Eben <[log in to unmask]> wrote: > Hello all, > > A little context: the MODS and RDF Descriptive Metadata Subgroup > ( > https://wiki.duraspace.org/display/hydra/MODS+and+RDF+Descriptive+Metadata+Subgroup > ) > is a group of cultural institutions working together to model MODS XML > as RDF. > > Our project diverges from previous efforts in this domain in that we're > trying to come up with a model that takes more advantage of widely-used > vocabularies and namespaces, avoiding blank nodes at all costs. > > As we work through the list of MODS elements, we've been stumbling on a > few thorny issues, and with our goal of making our data as shareable as > possible, we agreed that it would be helpful to try and get the input of > folks who have more experience in harvesting and parsing RDF from the > proliferation of data providers existing in the real world (see > https://datahub.io/dataset for a great list). > > Specifically, when consuming RDF from a new data source, how big of a > problem are the following issues: > > > #1. Triples where the object may be a string literal or a URI > > For example, the predicate 'dc:subject' from the Dublin Core Elements > vocabulary has no defined range, which means it can be used with both > literal and non-literal values > ( > http://wiki.dublincore.org/index.php/User_Guide/Publishing_Metadata#dc:subject > ). > > So one could have both in a data store: > > ex:myObject1 dc:subject "aircraft" . > ex:myObject2 dc:subject > <http://id.loc.gov/authorities/subjects/sh85002782> . > > > ... versus ... > > > #2. Using multiple predicates with similar/overlapping definitions, > depending on the value of the object > > For example, when expressing the subject of a work, using different > predicates depending on whether there is an existing URI for a topic or > not: > > ex:myObject1 dc:subject "aircraft" . > ex:myObject2 dcterms:subject > <http://id.loc.gov/authorities/subjects/sh85002782> . > > > We're wondering which approach is less problematic from a Linked > Data-harvesting standpoint. Issue #1 requires that the parser be > prepared to handle different types of values from the same predicate, > but issue #2 involves parsing an additional namespace and predicate, etc. > > Any thoughts, suggestions, or comments would be greatly appreciated. > > Thanks, > Eben > > -- > Eben English | Boston Public Library > Web Services Developer > 617-859-2238 [log in to unmask] >