A query for those who are curating collections of letters and correspondence using Omeka S.
I am not able to find a Dublin Core Term that is correlative to the Recipient or Addressee of a letter.
The Author of a letter is represented by the DCT ‘Creator’ – but there seems to be no term I can use for the person that Author is actually writing to! This is quite important for any network analysis, and also for when that Recipient/Addressee has other key contributions to a field of study such as being an Author of manuscripts, or a Collector of objects…
Anyone have any ideas about how to represent the Recipient or Addressee?
Is it okay to mix and match ontologies like Dublin Core Term and Bibliographic Ontology in one Resource Template? And how would that work with a CSV Upload for Item Creation?
Not only is it okay, it’s encouraged. Linked data is is vocabulary agnostic: it’s not reliant on any one domain of knowledge. You can draw from any vocabulary, whether it’s generalized like Dublin Core or more precisely defined like BIBO. Resource templates and the CSV Import module reflect this flexibility.
While it is technically possible to mix and match properties from different vocabularies to describe a resource in linked data, in general (and also in Omeka S), it is generally not recommended. This is because mixing vocabularies can lead to confusion and interoperability issues.
Each vocabulary is designed to represent a specific domain of knowledge, and its properties are carefully chosen to reflect the relationships between concepts within that domain (described in OWL). When you mix properties from different vocabularies, you may be violating the constraints of these vocabularies and creating inconsistencies in your data. This can make it difficult for machines to understand the relationships between different pieces of data, and it can also make it more difficult for humans to interpret the data.
In general, it is better to use a single vocabulary to describe a resource in linked data. This will help to ensure that your data is consistent, clear, and easy to understand. However, there are a few situations where it may be appropriate to mix vocabularies. For example, if you are describing a resource that has properties that belong to two different domains, you may need to use properties from both vocabularies. However, even in these cases, it is important to be careful and to make sure that the properties you are using are compatible with each other.
Here are some general guidelines for mixing vocabularies in linked data (so applicable to each system managing linked data, like Omeka S):
Only use properties from other vocabularies if they are truly necessary to describe the resource.
Familiarize yourself with the constraints and relationships between the concepts in each vocabulary.
If you need to use properties from multiple vocabularies, consider using mappings to ensure that the properties are compatible with each other.
By following these guidelines, you can avoid the pitfalls of mixing vocabularies and create linked data that is consistent, clear, and interoperable.
You could even argue that Omeka S is making the mixing of vocabularies too easy (in Resource Templates and adding of Items), which could to inconsistent, unclear and incompatible … The vocabularies in Omeka S consist of classes and properties, but not the domain and ranges of properties or subclasses/equivalent classes. So constraints and relationships cannot be used in the user-interface of Omeka S (wouldn’t that be a cool feature!).
Thanks for this, @coret. It’s a really interesting issue and I think you can understand why I asked the question in the first place! As a museum professional with an understanding of how much work has gone into designing ontologies for specific orders of thing, I think twice about these issues and am also thrilled by what semantics and linked data can/could do for interdisciplinarity. But if you were describing/cataloguing correspondence with Dublin Core Terms, what Term would you use for Recipient? Looking forward to your advice!
Thank you for this. It’s a well-thought-out and nuanced take. I am sympathetic to your concerns, and agree with your general guidelines for mixing vocabularies, but I do think that most projects don’t need to concern themselves with certain intricacies of RDF. One of our missions is to nurture adoption of linked data and to provide a platform for projects to grow and mature. We think that imposing too many rules and constraints (especially from the onset) would hinder this mission. Therefore, for better-or-worse, I tend to encourage a more lenient approach to data modeling than some linked data enthusiasts are comfortable with.
Even so, I appreciate your input and thank you for keeping me honest.