New OmekaS user here, I’ve been tasked with finding a new platform to migrate an existing database to, and after considerable issues trying Arches we’re now looking at OmekaS instead. I’ve been impressed with the ability to achieve so much more out-of-the-box and with adding Modules to help solve specific issues, but I’ve now struck my first blocker issue that I was hoping I could get some guidance on.
The issue is our existing CIDOC-CRM model (mapped from an older relational model) depends quite heavily on having multiple properties of the same type distinguished by the label/name. When mapping that into OmekaS Resource Templates we’re unable to repeat that pattern in the way we expect.
For example, our Actor class (E39_Actor) has multiple P76_has_contact_point properties for Phone, Fax, Email, Website, and Address. In Arches we just added multiple Nodes with those names. In OmekaS we are unable to do this, even with Advanced Resource Templates module as they all have the same type of Text. The same issue applies to use of is_identified_by for names etc.
I guess an more “graph-y” OmekaS style solution would be to have a single Contact Point property with multiple Values that uses annotations to attach a Contact Type to each Value, but that feels clunky in the UX and a bit back-to-front and likely to confuse our users who may forget to add them. Alternatively, it could link to a Contact Point class/item with the Type and Value, but the thought of tens of thousands of Items with just random phone numbers or addresses seems a bad thing, not to mention again being very clunky UX.
Is there a “nice” way to set things up so when our users view or enter data they are able to see a more traditional flat form style view of the data? Would this be better done with a say a Collecting form for the data entry instead? Or something else I’ve not yet learned of?
We’re happy that you’re evaluating Omeka S for your new platform.
If I understand you correctly, you want to use the one property for several distinct types of values. Is this correct? People often ask us a similar question about how to classify multiple types of identifiers for dcterms:identifier: like ISBN, ARK, DOI, etc.
You’ve already mentioned two solutions: use annotations to differentiate between the values, and build out the entire graph, ponderous as it may be. Another solution we recommend is to use more specific properties. CIDOC-CRM may not have specific properties for email, website, phone, etc; but there are other vocabularies that do. You could use, say, schema:email, schema:url, schema:telephone from the Schema.org vocabulary. If you’re tied to CIDOC-CRM, there’s no reason to not include them as well.
Thanks Jim. Yes, the dcterms: identifier for ISBN/DOI/etc example is exactly the situation we face in multiple areas. I’d definitely want to hear what the usual recommendation for that is. A similar example would be archaeological site identifiers, such as modern name, ancient name, geolocation, Pleiades, Geonames, etc which are all variations on “is_identified_by” in CIDOC-CRM.
I’d have to look to see how including extra ontologies might affect the data we link/share with external parties using the existing CIDOC-CRM mapping. I guess we could have different internal and external models, it is just a reference mapping after all, but I’d need to see if that would require custom code for exports and APIs.
While schema.org can probably cover the specialised contact points the way we want, there may be circumstances where we’d have some repeated properties that might still needing annotation, e.g. multiple URLs or emails for different purposes.
If we were to go the annotations route, is there a way to configure it so the annotation is required? Could we make a custom input widget for it? I’m assuming we would be able to customise the default view (below) to be more form like, i.e. have the type annotation as the field label?
Alternatively I guess I could just create my own ontology extending CIDOC-CRM that includes all the specialised properties we need
Given your project’s commitment to CIDOC-CRM, I recommend following a rigorous adherence to the ontology. That could mean one of two things: 1) build out the entire graph or 2) extend the ontology to include all the specialized properties you need. The former will be clunky, but it will unambiguously reflect the graph as-is . The latter, while not strict CIDOC-CRM, should satisfy most stakeholders and would be easier for data entry and more comprehensible to the end-user.
Given your reservations about value annotations, I’m hesitant to recommend that route. There is no way to make an annotation required. Nor is it feasible to make a custom input widget beyond the existing data type interface. There is interest in making templates for annotations, but that is not on our road map at the moment.
But, if you’re interested, here’s how I’d handle an annotation for cidoc-crm:is_identified_by: set the annotation property to dcterms:type, the data type to Text, and the value to “modern name”. This will reify the statement as being of the “modern name” type.
Thanks for the advice Jim. I think we’ll go with the CIDOC-CRM extension to start with to try keep the model and UX closer to the current experience. It should also make mapping of data easier. If we hit issues with that then we can try fully building out the graph.
