Dear Community,
I’ve been using omeka and omeka S for years.
I’ve also been using CIDOC-CRM for years, like many people in the cultural heritage community.
Omeka S offers the possibility to handle ontologies, but for event-oriented ontologies like CIDOC-CRM:
It’s hard to enter/maintain information in scattered elements. For example, information related to events in the life-cycle of the physical object (e.g. date of production) is not directly part of the metadata of the `physical object’. People using CIDOC will understand!
Omeka-S UX is not designed to display information from scattered items on the same page. So information about Physical Object and related Events are not displayed on a single page.
manually fill the lifecycle event data directly into the physical object metadata (with some special properties)
a script creates events for this data
the script links the newly created event to the Physical Object to make it CIDOC CRM compliant.
Of course, the script checks if an event already exists, offers to update the event data, etc.
Python scripts can be found here: GitHub - mquantin/omekaSedit: python scripts to edit omeka CMS data
The figure below shows what the script does.
A refactoring of these scripts would be nice and more presentable, but laziness… it works!
Displaying the event data in the Physical Object page
The idea is to display a Physical Object page with 2 columns:
on the left, the metadata of the Physical Object.
on the right, the metadata of each event associated with the Physical Object
The image below shows how it looks like:
A dirty PHP theme I created (I’m bad at PHP) does a pretty good job in my case:
Dependencies
for the theme: omeka-s v4 fork. Some clear and simple changes (from branches). PRs to the official repo. Some PRs have been merged, others not (yet?)
for the scripts: Omeka-s tools fork. Some features were missing from the Python API.
Dear reader, I hope you find it useful, don’t hesitate to fork and PR!
I’m going to leave the lab here now, and I won’t be working on it any more.
Thank you for sharing your work. I have been considering a very different approach to this problem and I wonder what you might think of it. Rather than covert a property (in your case dcterms: Date) into a relationship to another class, we are considering simply modeling the short cut in our custom ontology. So in our case we would articulate a property Production Date that is a short cut to P108_has_produced > E12 Production > P4_has_time_span. We have seen this done in other custom ontologies like AO_Cat (The AO-Cat Ontology) which also subtypes from ontologies that use multiple inheritance from CIDOC-CRM.
Did you consider this and reject it for specific reasons. If so, can you share those? Thanks again.
I’m not super familiar with CIDOC-CRM specifically, but there is a feature we’re looking at that might be relevant to the workflows I think you’re talking about.
We’re doing some initial work on a feature where you get an additional choice when setting a Resource value for a property: an option to make a new resource with a simplified creation form, and then the value will link to that newly-created resource. The idea is to simplify data entry for workflows that rely on connections between multiple resources; instead of needing to make the things you’re going to link to ahead of time (or as here, convert them after the fact), you can create them while working on the “main” resource and without leaving its context.
@jflatnes – that sounds like a really nice addition for people who do want to model their data that way (class >> linking property >> class >> value property. What I was referencing is creating custom properties in our ontology that in the end are just “text” but semantically are modeled as a shortcut for the above.
@nxm oooh smart workaround this custom ontology of CIDOC-CRM shortcuts.
As CIDOC is really even-centred, the following reasons prevent me from doing it seriously:
philosophy: a huge shift from the CIDOC way of modelling the information. I like it as it is: light, powerful and flexible.
heaviness: many properties to create. Lot of documentation to create, resulting in a complex and heavy ontology (and documentation)
loss: the loss of modelling capacities is unavoidable and hard to evaluate
maintenance: New needs of recording may require complex (or dirty) ontological solution to create the path
standard: the data is not expressed and published in a standard language; translation (mapping) is needed. The “Rosetta stone” has to be explicitly mentioned, well known, accessible, published, up-to-date (without confusion) and maintained.
approach: my problem was just about displaying and didn’t want to solve by a workaround in modelling.
I thought of this kind of approach, but I didn’t do it in deep.
Actually, I have created and used a single shortcut called “conceived” to directly link the physical object with the conception event (E65 creation). It is defined here: has conceived (conceived by) – P1
On the admin side
It could replace my scripts and ease the maintenance of the items.
Please note that in CIDOC-CRM the properties are always directed from the eventto the physical object. Invert properties exist and may solve this issue.
On the public side
No change is announced.
The display of the resource remains an issue.
Then my theme remains a solution. Isn’t it?
Nested Data Types looks a little closer to the core’s value annotations feature in principle: it lets you do more nested data but constrained still to a single item or resource. The one we’re doing now is for when you do want full, real items for the “other side” of these links; they’ll be independently searchable, browseable, editable, since the feature is just making fully-fledged items.
Stepping away from the CIDOC-CRM context, the idea would be something like, you have a site where you want to have items for both works and authors; what this is looking to smooth is a data-entry experience where you’re working through a list of works and encounter an author that’s not yet added, you could add them without having to leave the current item and start over or work in multiple tabs simultaneously. Of course the principle extends to many other possible patterns, but that’s a simple example.
You’re correct that the feature doesn’t bring any changes to display; it will just use the normal linking/linked-resources systems that are already used for “resource” type values. A theme is definitely a valid choice for altering the display to be more geared toward a site heavily based on linked resources, pulling more data into single pages. A module might also be a good fit for that kind of presentation, particularly one using the 4.0.0+ “resource page blocks” feature; it could provide the implementation for pulling in linked resource data independently of the design of any one theme.
Thank you for sharing the ideas and the code. I started exploring CIDOC-CRM back in November when it was recommended by @SharonLeon in a thread about museum vocabularies and encountered the very same challenges regarding the structure. I will look into your solution.
/screenshot.png)
