Can I combine properties from different vocabularies in Omeka S?

Omeka S
1

Hi everyone,
I’m working on a project using Omeka S, and I need to describe resources by combining properties from different vocabularies. For example, I want to use a property from Dublin Core along with one from FOAF in the same resource.

Conceptually, is this approach valid within the framework of Omeka S and linked data principles? Are there any best practices or limitations I should consider when mixing properties from multiple vocabularies?

Thanks in advance for your insights!

2

Feel free to mix properties from multiple vocabularies. When selecting your properties, you are essentially creating an ontology for your specific domain. In doing so, there are no restrictions to which properties you choose, as long as they satisfy your description requirements.

1 Like
3

The answer from @jimsafley answers the question if Omeka S is capable of using properties from different vocabularies in a resource (template) - yes indeed.

To answer the question if this approach is valid within the linked data principles: yes, you can mix properties and classes from different vocabularies like FOAF and Dublin Core when describing resources using linked data. This is one of the strengths of the linked data and RDF (Resource Description Framework) model—it allows you to create flexible and interoperable descriptions of resources by combining terms from multiple vocabularies.

But there are some considerations:

  • Semantic Compatibility: Ensure that the properties and classes you combine are semantically compatible to avoid creating incoherent descriptions.
  • Inference and Reasoning: Some vocabularies have formal semantics that may affect how reasoning engines interpret combined data. Be aware of potential conflicts or implicit assumptions.
  • Namespace Declaration: Always properly declare the namespaces for the vocabularies you use, so the terms are clearly identified.
  • Community Standards: Check if there are community standards or best practices for combining the vocabularies you’re working with. For example, FOAF and Dublin Core are commonly used together, but other vocabularies may have less overlap or different intended use cases.

To give an example and some Omeka S feature requests: if you have a resource of class sdo:Person with properties sdo:givenName and sdo:familyName it is semantically incorrect to add a foaf: workInfoHomepage. As the domain of the sdo properties is a sdo:Person and for foaf the domain is a foaf:Person - two different things! You can ‘fix’ this by declaring the resource is both a sdo:Person and a foaf:Person as is usual in linked data, but this is not possible in Omeka S.

I wish declaring multiple classes on a resource would become a possibility in Omeka S!

When adding a property from another class to a resources with a specific class, Omeka S will not warn you. This is because when Omeka S imports vocabularies, only basis information about classes and properties are stored, not the domain (specifies the class of resources to which the property can be applied) and range ( the class of values that the property is expected to have) information.

I wish the domain and range information would be retained on import so Omeka S could warn its users about the semantics of their resources (and resource templates), making Omeka S an even better linked data collection management system!

3 Likes
4

Thanks for your reply. We are newly exploring Omeka S, and I would not class myself as an expert in linked data, so it’s helpful how you have highlighted areas where Omeka S is a bit lax in its implementation.

I don’t know whether you have any expertise in museum vocabularies? I opened a separate thread a few weeks ago under the topic Vocabulary for museum objects and you may be able to offer some advice. In our case we have identified a single vocabulary that looks good, but we would not want all of the classes to be visible as items for the user.

We are torn between implementing a vocabulary properly, respecting the domains and ranges, and just “making it work” with a cavalier attitude to properties and bending the rules.

If we want to be really strict and not misuse a vocabulary, ironically the easiest solution feels like just making up our own classes and properties to meet our needs. But then we would lose any possible advantages of linked data because no-one else would know what our data meant.