A cascade of constraints?
Closed this issue · 2 comments
One way out of the problem of over-constraining the openWEMI vocabulary would be to create a cascade of related (probably sub-classed) vocabularies where the properties have additional constraints. Something like:
Least constrained
Five classes and 3 properties (or 6 with inverses) with good definitions but no domains or ranges defined. (Can WEMI still be sub-classed to Endeavor?). Being somewhat informal, this could use the schema.org domainIncludes and rangeIncludes which are helpful but not standard.
More constrained
Properties are given domains, but are defined as owl annotation properties so they can be used with strings. Either the property names or the vocabulary name must be different (as in dc1.1 and dcterms). This solution does not embody the structure that we have defined.
Most constrained
Properties are given domains and ranges. All properties are therefore owl object properties.
Note that if multiple levels of openWEMI are defined they could be mixed-n-matched in instance data.
This intersects with #43 and if one of these solutions is chosen, then we have to decide if adding specific properties makes sense within that solution. It is also possible that additional properties could be added along with additional constraints. I haven't thought that far.
My vote would be for the "most constrained", but dropping the OWL semantics (owl:ObjectProperty could be replaced with rdf:Property, and owl:unionOf could be replaced with rdfs:range openwemi:Endeavour). This eliminates some of the logical overhead of OWL, and is closer to the approach of high-level vocabularies like DC [1].
I think setting up the range as openwemi:Endeavour would provide the most flexibility (equivalent to Work or Expression or Manifestation or Item), and a resource could still be inferred to be of a more specific type through the domain (if A openwemi:expresses B, then we can infer that A is an openwemi:Expression, with the same being true for the inverse). This also supports a resource belonging to more than one class (type), i.e. both a openwemi:Work and openwemi:Expression (see El Diablo from the comics example).
Additional constraints or more distinct semantics, additional properties (as mentioned in #43) with specific domains/ranges (e.g. openwemi:instantiatesWork), etc. could be added in an extended openWEMI vocabulary (e.g. openWEMI-XL). This extension might also be a good place to define other relationships (isPart/hasPart, etc.) if necessary (see #18).
I think annotation properties are more for metadata describing the vocabulary components, like rdfs:comment, rdfs:label, etc.
[1] https://www.dublincore.org/specifications/dublin-core/dcmi-terms/dublin_core_terms.ttl
June 14 meeting decided to define domains and ranges for the properties.