Vocabularies and Ontologies

[fidelthomet]

this is for collecting pros and cons of using a fixed set of given properties and classes versus a more open and flexible approach - or something in between

[fidelthomet]

using existing ontologies
pro

• we'd follow a standard, people familiar with that standard will easily understand our data
• importing our data in systems that use the same standards would be simplified
• others have invested tons of effort, we don't need to reinvent the wheel
• translations of property and class names may already be provided (although often limited, i.e. cidoc crm)

contra

• we have not yet found an ontology that fits our needs well
  • using a less known/supported but better fitting ontology takes away some of the benefits of using an ontology at all
• we'd force our data into a preconceived system probably biased towards western/colonial world views
• when importing data from external sources we'd need to translate them into our ontologies
• we'd probably end up with a large number of unused properties & classes
• existing ontologies favour preciseness over comprehensibility

using custom solutions
pro

• high level of flexibility
• we can create new classes and properties on the fly; no need to work with ill-fitting ones
• support for various perspectives and knowledge systems
• we can prioritise classes and properties that are easy to understand and communicate

contra

• less easy to reuse our data in future projects
• chance of creating duplicated (or very very similar) classes properties

[fidelthomet]

mixing

there are various option on mixing existing and custom solutions

extending / simplifying existing ontologies
we tried that with cidoc, but ended up losing interoperability while still being constrained by their basic assumptions

adding an exact match property on classes and properties
we have that for entities already, would be fairly straightforward to add support for classes and props as well. could ease things for import / export but requires additional cumbersome work. but an easy to use import could also provide us with translations

different ontologies for different graphs
we could use different ontologies in different contexts, i.e. stuff imported from gbif could make use of (and be limited to) gbif properties and terminolgy, while handcrafted flow charts could support something more open and flexible. this will likely increase complexity for data editors, as it might not always be obvious in which context which properties/classes are available

[fidelthomet]

flow charts and ontologies

there might be some fundamental conflicts of objective. ontologies (and linked data, network graphs, …) are all about coherence and consistency. flow charts (especially in the way we want to utilise them) are about communicating.

explicit/implicit relations

we have a set of consecutive activities taking place at a single location. to reflect these relations on the data level (and to support answering the query «which activities take place at the location?» we'd need to draw edges between all of these activities and that location. In a flow chart the same could potentially be pointed out by connecting the location to the first activity and arranging the entities accordingly. Drawing edges between the location and every activity is not only unnecessary but would obfuscate the flow chart making it more difficult to understand.

proposal

use the linked data approach for imported data and graphs that are not primarily geared towards laypeople; use the flow chart approach for everything that should be communicable to a wider audience