Using multiple ranges / inferencing

[kcoyle]

OpenWEMI defines multiple ranges for some of its properties. The purpose of this is to permit the creation of metadata applications that do not require that all four openwemi classes be included. First, the ranges are defined as:

expresses (range: Work) expressedBy (range: Expression) manifests (range: Work or Expression) manifestedBy (range Manifestation) instantiates (range: Work or Expression or Manifestation) instantiatedBy (range: Item)

Note that the ranges are designed to be open but at the same time to support the levels of abstraction, from Work to Item. No property has a range of a less abstract level (e.g. a manifestation that instantiates an item). These ranges document intent. It is less clear to me how useful they are for inferencing.

For example, a vocabulary that defines a subclass of openwemi:Work and a subclass of openwemi:Manifestation, but does not make use of the concept of expression, can say that:

myResource myInstantiates myOtherResource

and myOtherResource can be inferred to be either a Work or an Expression. (Presumably a vocabulary based on openwemi can further constrain its properties to limit ranges, so myInstantiates could be defined with a range of myWork.)

My questions:

1. is this use of rdf:range appropriate for what we intend, or should we be either loosening this with rangeIncludes (which was discussed and rejected by the WG) so that there is no inferencing is implied?
2. Or should we make all ranges openwemi:Endeavor and allow any relationship, even those that violate the abstraction levels?
3. Would there be any practical purpose to using a combination of WEMI and Endeavor, such as:
   • manifests (range: Endeavor or Expression)? This gives some guidance but allows flexibility.
4. Should the documentation suggest that people use the xBy properties for greater precision?

[tombaker]

I touch on the case of multiple ranges in the issue about definitions.

[kcoyle]

See: https://www.jbusse.de/lovs/dcmi-openwemi.html for details.

tl;dr - We wish there was a better solution that does what we want.

busse: IMHO best solution: Do not model domain and range at all. IMHO best solution: Do not model domain and range at all, at least not with rdfs:domain and rdfs:range. This is because these language elements from RDFS (and OWL) have semantics that are misunderstood by many people.

As you can see above we had trouble coming up with an ideal solution. The main purpose of the domains and ranges in OpenWEMI is to maintain the directionality of the relationships between classes. The classes have a meaning that goes from most to least abstract, and we want to make that a validation point because it goes to the heart of the semantics of WEMI and OpenWEMI:

At the same time, not every application will have use of all four OpenWEMI classes, so we wanted to allow for relationships between the classes that retain the basic semantics but that aren't strictly linear in the way that LRM and LRMoo require. We want it to be valid to not use all of the classes (in vocabularies or in instance data, as in the Open World Assumption) but still be consistent with the abstract-to-concrete relationship. If someone creates instance data with a Work that expresses an Item, it should be possible to detect that as an inconsistency.

Unfortunately RDF only has domains and ranges to provide this feature. If we used something like "rangeIncludes" we would not be using RDF itself. That would greatly change the semantics ("rangeIncludes" is a suggestion, not part of an RDF vocabulary model). Below I'll go back over the numbered suggestions in the opening comment in this issue to fill those out a bit.