I’m new to Omeka S. We have an extensive database and consider to migrate from Collective Access to Omeka S.
The database has the data type book and the datatype person (and other data types). The books can be linked to one or more persons (the number is arbitrary) and there are a number of different types of relationships between book and person. So, in the old software we would create a link and select a link type to express that. The link types are: “is connected to”, “assumed connection to”, “belongs to” and “supplied by”.
What is the best way to model that in Omeka S? I considered creating a separate property for every link type. However, there are number of data types that can be linked (books and persons are just examples) and there is a number of link types for each combination which would result in a lot of properties.
How many types of links do you think you’re talking here? I’d tend to agree that having them be properties is probably the most natural expression of that relationship.
There are other options, like using a more generic property like “Relation” and then describing the linkage with an annotation, but I don’t think I’d recommend going that route with what you’ve described here.
For the datatype book, person etc, there are multiple ways:
use the classes :
– it will be necessary to use multiple ontology to specify the content (ex: “Book” is in the Bibliographical Ontology, “Person” is in the Friend of a friend, “Collection” is in the Dublin Core Type etc.) Be careful if you expose your metadata with OAI, some of bases doesn’t accept other vocabulary than Dublin Core
– in the same way you can, if exposition with OAI is not your object, use the plugin Custom Ontology to create your own Classes
use the properties:
– if expose your metadata with OAI is important you can choose a property like dcterms:type, hasFormat or medium…
– in the same way you can, if exposition with OAI is not your object, use the plugin Custom Ontology to create your Properties
The advantage of classes is they are unique in the resource metadata and they are independent from properties in the search.
For links between resources (same as jflatnes):
use properties with the type “Resource Omeka” to link the property to an other resource (best way to my mind). In this solution, the property itself take the signification of the relation (ex: dcterms:creator = Link to the item Claude Monet (class foaf:person). There are properties easy for that like dcterms:isPartOf, dcterms:hasPart, dcterms:hasVersion, dcterms:isReferencedBy etc but maybe not enough ?
if it is not enough, you can choose some properties and precise in the template a better label. Be careful if you expose in OAI because the sens of the properties can have an impact.
in the same way, if is not enough and if expose your metadata with OAI is not important, you can use the plugin Custom Ontology to create your own properties.
you can also use annotations on properties like “Relation” but the research in annotation and the readability of them in the resource pages is not perfect yet
Thanks a lot for your answer. It’s a database for tracking the provenance information of books in a library. There are five types of objects: “Person”, “Volume” (a book), “Mark of Provenance”, “Collection” and “Aquisition journal entries”. All these types allow links between them. Sprcifically:
Person → Person
is member of
related to
has father
has mother
is grandchild of
is sibling of
is acquainted with
is connected with
is heir / successor of
possible connection to
no known connection with
is married to
not identical with
Person → Mark of Provenance
assumed connection to
is connected to
is supplier of
Person → Volume
is owner of
is restitution recipient of
is supplier of
is connected to
assumed connection to
Person → Collection
is related to
Volume → Mark of Provenance
contains mark of provenance
Volume → Acquisition journal entry
has entry in accession journal
Volume → Volume
is part of
Volume → Collection
is part of
Mark of Provenance → Mark of Provenance
similar/comparable to
So Person would need 22 properties, Volume 4 and Mark of Provenance 1 property.
I did think about annotations but it’s more or less hidden in the backend which is not very user friendly to my mind. What do you think?
For Person → Person, Person → Mark of Provenance, Person → Volume, you have a lot of information that we don’t have in the DC.
Annotations will be the best way, but some developments are necessary: public research and theme at least.
If you do not have developers in your institution or the budget for a development service, and you do not particularly wish to expose your datas in OAI PMH, the simplest way is to make in-house properties (Omeka S - Custom Vocab) or add specific ontologies to your field of study (you can use Linked Open Vocabularies to search some vocabularies).