Omeka-S vocabularies and RDF

Omeka S
1

Hi all, just checking in on whether anyone is using RDF vocabularies beyond the ones included in Omeka-S (which are Dublin Core, BIBO, and FOAF)?

We have a specific documentary editing need to include Authors, Recipients, and Names Mentioned. There are a couple of options:

  1. Create a custom RDF (not sure how yet) and forgo inter-system compatibility (at least for now)
  2. Repurpose fields (i.e. non-standard use) from existing RDF vocab (BIBO has some potential)
  3. Identify a useful RDF vocabulary to import (any suggestions?) that is slightly more standard
  4. Attempt to wrestle with TEI or TEI-Lite, unclear if there is an importable RDF vocab
  5. Merge all names into a single field, but perhaps append an identifier such as (A), ®, and (N) to each name (thus creating potentially triplicate names in the system, but being identifiable as author, recipient, or name mention)

Any thoughts, advice, use cases/scenarios, etc.? Appreciate it!

BEN BAKELAAR, MLIS
Thomas A. Edison Papers
Rutgers, The State University of New Jersey

1 Like
2
  1. A custom vocabulary does not forgo inter-system compatibility if it is a) written to extend existing vocabularies and b) published with documentation. Just define your particular domain using references to existing classes and properties using e.g. rdfs:domain, rdfs:range, and owl:sameAs.
  2. There is nothing wrong with repurposing fields if the fields are abstractly defined. Omeka S lets you give alternate labels and comments to properties for this exact purpose!
  3. Check out Linked Open Vocabularies
  4. Even if TEI had an RDF vocabulary I’m not sure how helpful it would be given that its purpose is to encode text, not to describe resources.
  5. I highly recommend against this, unless you’ve exhausted all other possibilities. It could be a good ad hoc measure until you can implement another vocabulary.
3

Thanks Jim, this reply is very helpful, as well as the Linked Open Vocabularies site!

We’ve crossed out #1, #4, and #5 as a result.

As a curiosity, do you have any idea why Dublin Core doesn’t contain an “Author” field, and BIBO only contains “List of Authors”, but not an individual author? Meanwhile, BIBO contains “Recipients” which is useful to us in regards to historical documents, and we understand why Dublin Core doesn’t have this.

4

DC and BIBO differ in their domains: the former defines any resource and the later defines bibliographic resources. DC doesn’t contain an author field because, in their judgement, dcterms:creatorapplies generally across domains. Because of this BIBO instructs its users to use dcterms:creator to describe authors, but you are free to use any property that makes the most sense in your domain.

5

And Jim while this is fresh, do you have any comments on the gap between RDF (I think primarily a “web” spec) vs. institutional ILS/library systems which typically seem to use XML specs like METS/MODS? Is that what the plugin “connectors” are for? And if so, are there plans for 2-way communication? Because right now it seems like it’s just 1 way “digest” from an ILS into Omeka.

6

METS/MODS are legacy standards for encoding library objects and bibliographic records, respectively, using XML. RDF is a general purpose data modeling specification. Older XML specs use a hierarchical model to represent relationships between resources and their properties, while the newer RDF specs use a graph model. So, they are tangentially related, but it’s not helpful to compare the two, especially in relation to Omeka S connectors.

We have no plans to implement true syncing between Omeka and institutional repository systems.

1 Like