Representation of information

Omeka S
1

Hi,
I am wondering about the representation of information in Omeka S.
What if I want to express relationships between resources that are not items within the meaning of Omeka-s? For example, an item describes a building; Another item reports an event. How to express the fact that the event took place in the building ? (Assuming that I have an ontology that allows to say all this). Do I need a triple store or a database next to Omeka S?
Thanks in advance.

2

If you have an ontology, you can import that into Omeka S and then just use those properties to represent the relationships when you create items. How those kinds of complex relationships are displayed might require some additional theme work, but all the basics of the data are there, though complex ontologies get simplified when imported into Omeka S (e.g., subproperties and inferencing assertions are flattened).

3

If I am not mistaken, you create items for any entity even if there is no associated media ? In my example above, assuming that i imported an ontology providing those classes, events and buildings would become items just to be subjects or objects of semantics triple ?

4

That’s what I’m imagining, yes.

5

You can look at this topic about representation of a group of properties. I have been thinking we could imagine an other kind of resource (sub-items).

6

I think a true sub-item resource type would be much harder, if it could work at all. For one, you’d have to build the entire interface to make those connections. And, it would lose the interoperability of LOD outside of Omeka S.

Using existing ontologies would be much easier to handle. The hard part then would be customizing the theme you use to make it all display the way you want, but that’ll be easier than the data model work required for a subitem resource.

7

It would be only for ergonomic purposes.

Currently in Omeka S, you can have

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:foaf="http://xmlns.com/foaf/0.1/">

 <foaf:Person rdf:nodeID="john">
   <foaf:name>John Doe</foaf:name>
 </foaf:Person>

 <foaf:Person>
   <foaf:name>Jane Doe</foaf:name>
   <foaf:knows rdf:resource="#john"/>
 </foaf:Person>

</rdf:RDF>

But you cannot have

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:foaf="http://xmlns.com/foaf/0.1/">
 <foaf:Person>
   <foaf:name>Jane Doe</foaf:name>
   <foaf:knows rdf:parseType="Resource">
       <foaf:Person>
         <foaf:name>John Doe</foaf:name>
       </foaf:Person>   
   </foaf:knows>
 </foaf:Person>
</rdf:RDF>

Both are equivalent, but when you build Jane item, it is much more ergonomic to define John as sub-item rather than open a new tab to create John before adding it as resource for Jane.

This example is pretty bad, because both items are Person. But some kinds of item have no semantic by themself, like the “groups of properties”.

8

I see the issue – it’s all over Omeka Classic, too, for example in creating an Item and assigning it to a Collection. If you forget to create the Collection first, it’s a pain.

I’m still concerned about the amount of data model and interface work that would be involved. This looks to me like the inconvenience of the order of item creation will be much smaller then the refactoring for this kind of thing. Indeed, for the API, I don’t think that it could handle blank nodes like this, either for input or output, but I’ll ask the other developers. My suspicion is that it would be an awful lot of changes.

9

I also think it will require lot of changes, but I vote for it.
I added another example in the Repeatable group of fields topic, why it would be helpful.