Our foundation has several collections, among which a book library. We want to switch from our (own-designed) relational database to Omeka S.
Currently, we use a table ‘books’ that is related to a table ‘persons’, and the table ‘persons’ is related to a table ‘roles’ (author, illustrator etc.)
I have read several threads on this forum on this subject, but still can’t seem to figure out how to establish these relationships in Omeka.
Example: In Omeka, I would use ‘creator’ for the author, and ‘contributor’ for all the other co-authors, illustrators etc. The question is: what is the best way to link to their roles?
Important to note is, that not only one (1) book can have several contributors, but one contributor can have several roles as well… E.g. a certain person can be author of book 1, and co-author or illustrator of book 2.
Eventually we would like to create a theme that is able to show things like:
all books that a given person has contributed to
all persons that have contributed to books in genre ‘X’
For that to be achieved, we need unambigious datasets for both ‘persons’ and ‘roles’ (to secure the integrity) and relationships between the two.
I’m sure there is some consensus on how to do this the ‘proper’ way with document-based databases, however I’m afraid my way of thinking is still too much in the realm of relational databases…
If I were to do this, I would create a Resource Template for the books and a Resource Template for persons. Then, I’d develop a Custom Vocabulary of the roles, and then use Value Annotation to assign the roles to the inputs for the Creator and Contributor properties. This will allow you to capture all the data that you want to include.
However, it is not currently possible to use a bulk import of data via the CSV Import module that would also include the Value Annotations, so if you’ve got a lot of existing data to move over to Omeka S you might want to take a different approach. Given this complexity, the other option would be to develop a Resource Template that draws together properties from several LOD ontologies that would allow you to specifically represent the roles in the main item description (i.e. without the reification of the annotation). Bibo, which is included in a basic Omeka S installation, seems to have many of the roles that you would be looking for, but oddly does not have illustrator, but Schema does, though it would have to be added.
Thank you SharonLeon. I tried using annotations and it works, albeit a bit cumbersome.
Especially since I have to select both the property and the custom vocab again for each annotation. Perhaps there is a way I don’t know of to set these in the resource template somehow (?)
Yes, we have to import quite a few records, so I think I’ll have to write some custom PHP to add the annotations to the records. I looked at the database and saw that at least three tables are involved: resource, value & value_annotation. I need to dig deeper to figure out if this is doable…
I have come across the question of how to assign a role (to creator / contributor) more than once. Perhaps a future version of Omeka S will make it easier to add or import annotations (or offer another way to create those relationships).
I want to underscore @SharonLeon’s suggestion to draw together more precisely identified properties from other vocabularies. It’s almost always a better idea to do this than to use value annotations, which are, as you note, a bit cumbersome. While it is true that annotations may be used to qualify a property, they are more accurately used to make a statement about a statement, e.g. to declare provenance, certainty, etc. about a fact. This is reification.
Looking at your use case, it is correct to use dcterms:creator as the author. It is typical for author lists to begin with the primary author followed by co-authors. Could you simply rely on the natural order of values to assume author and co-authors? If not, it’s acceptable to use dcterms:contributor. As for illustrator (and other contributor types), you could use the Schema.org vocabulary. It contains schema:illustrator and many other contributor-adjacent properties.
Just consider using other vocabularies like Schema.org to diversify your properties instead of using value annotations. Take a look at Linked Open Vocabularies for ideas of which vocabularies to import. I’ll be glad to help if you need further assistance.
Thank you @jimsafley , I took a look at schema.org and think this is the way to go for us.
I will yet have to find out how to query ‘all contributors to books of genre X’, as these will not be categorised under one term (‘contributors’) anymore. But that’s of later concern.
I’m not sure if this is the right place to ask, but one additional question comes to mind: I assume that it’s not considered bad practice to mix different (and partly overlapping) vocabularies, since we’re already using Dublin Core?
Thank you @sharonmleon, that is good to know. I added schema.org to the vocabularies. It looks like it has more than enough to offer for our needs
An important reason why we are switching to Omeka is because we want to work more in accordance with (professional) standards, such as those commonly used by museums and libraries when creating meta descriptions for collections. Our foundation is mostly run by volunteers and we do not employ a professional archivist or librarian.
So all the help we get here is much appreciated, thank you all!
