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.

[kcoyle]

Responding to Johannes:

OWL:unionOf "The union of two classes contains every individual which is contained in at least one of these classes. " From W3C

You are suggesting that we should use: "(1) z is an element of Work; or z is an element of Expression; or z is an element of Manifestation; or both, or all of the above."

That seems to be the same, to me, so I need you to explain the functional difference. Your code snippet is:

:instantiates
  a rdf:Property ;
  rdfs:domain :Item ;
  rdfs:range :WEM . 

:instantiatedBy
  a rdf:Property ;
  owl:inverseOf :instantiates .
  # given in openWEMI.ttl, but redundant:
  # rdfs:range :Item ; 
  # rdfs:domain :WEM .

:WEM a owl:Class;
    owl:unionOf (
      :Work
      :Expression
      :Manifestation) . 

I should mention that

1. OpenWEMI is a very high level vocabulary and as such inferencing will not be terribly useful. In addition we recognize that very little inferencing takes place (in our experience).
2. The "openness" of OpenWEMI is designed to facilitate more specific vocabulary declarations. Those declarations are expected to be specific to the resources being described and more constrained than OpenWEMI. If OpenWEMI had any further constraints we would eliminate possibilities in subordinate vocabularies.
3. One of the main "open" decisions was not to declare WEMI disjoint. Any downstream uses are free to do so. Imagine that an application wants E and M and I to be disjoint, but not E and W. (cf. BIBFRAME) If OpenWEMI declared all WEMI to be disjoint this would not be possible.
4. We discussed "rangeIncludes..." but wanted to stick to the actual W3C standard, especially since "rangeIncludes" is really only documentation. We also discussed not using ranges at all, but we wanted to keep the basic structure of W -> I.

I admit that our diagram is not strictly readable as OWL - I like your diagram, and it gives me an idea for a better one for us.

[kcoyle]

Copy from Johannes original email:

Subject:
#123,
#94

Feel free to forward this email to your collaborators or GitHub issues, etc., as you see fit.

(1)
Recently, a group of clever students and me tried to find a visualization for the range axioms from the normative OpenWEMI ttl file. You can find the result and a detailed discussion at

https://www.jbusse.de/lovs/semantic-of-disjunction.html

In any case, this provides a visualization for the classes from the normative ttl file.

(2)
In #94 you write:

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.

Please forgive me if I disagree: RDFS is not suitable for detecting this sort of inconsistencies. In particular, rdfs:domain and rdfs:range are used exclusively to derive explicit knowledge from implicit knowledge, "to entail". We worked this out in detail in our seminar, see

https://www.jbusse.de/lovs/semantic-of-disjunction.html#rule-rdfs3-semantics-of-rdfs-range

If you really want to formally express the original visualization, I again recommend replacing rdfs:range and domain with rangeIncludes and domainincludes. This immediately solves many problems. And if you actually want to support integrity checks, domainIncludes and rangeIncludes are the perfect solution.

(3)
In my opinion, the real cause of the problem lies in the fact that OpenWEMI does not want to treat the classes W E M and I disjointly. I am familiar with the argumentation of Renear and Dubin (2008), but it does not convince me.

One point is: Even if one were to follow Renear and Dubin, one would get a model that is not compatible with the WEMI terms from the FRBR tradition: A role-based OpenWEMI model would be structurally fundamentally different from all other WEMI models. ... But that's another discussion, I'll have to write that up somewhere else 😉

yours
Johannes