I’m considering Omeka S for a database project and wanted to learn more about how the data is actually structured. I’ve played around with an instance but want to see how the data I enter on the website is being stored - is there any documentation I can reference for this? I know it runs off SQL but am mostly curious about how things like Annotations could be imported / exported.
For reference, I am currently working with an XML document-based project and want to convert it to a relational database, as the relationships are one-way with my current format. While it causes a lot of headache, the hierarchical nature I’m working in right now lets me get really detailed and I’m thinking on how this detail could be re-structured in Omeka S. Annotations seem like they work, but I want to see how they are correlated with the items and fields to understand how that would transfer.
The documentation here is a bit scant. I recommend starting a dev instance of Omeka S up, and using dbeaver or similar to query the database, that way you get the most up to date information.
Right, we don’t really maintain any documentation of the database structure.
The basic structure for value and annotation storage is like this:
Items, media and sets are all “resources” that values can be attached to: there’s a one-to-many relationship from resource to values. A “value” row stores all the data for one piece of metadata: what resource it goes to, what property, the data type, whether it’s public or private, the language, and of course the actual value (and/or URI or linkage to another resource).
Annotations are basically a second level here: there’s actually another kind of resource which is value_annotation in the database: each value_annotation row/object is basically a container for the annotation values that are attached to a specific value. Each value row has an optional one-to-one connection to a value_annotation, and since the value_annotation is a resource, it can itself have whatever number of values attached to it, meaning you can have arbitrarily many annotations for a given “main” value.
The value_annotation object and the linkage of it to the parent value are really internal implementation details; when you add annotations through the interface or API they get created automatically.