dcmi / openwemi

OpenWEMI
Creative Commons Zero v1.0 Universal
27 stars 9 forks source link

About Endeavor #97

Closed kcoyle closed 5 months ago

kcoyle commented 6 months ago

This is a more expansive response to @danbri 's comment on issue #87.

The superclass Endeavor may lead to some confusion. Although WEMI are each subclassed to Endeavor, there are no properties in openwemi that would connect a WEMI-classed instance to and instance of Endeavor. This is best explained in diagrams. Here is the basic WEMI class structure:

    flowchart BT
    E((Endeavor))
    I((Item))-->|subclass|E
    M((Manifestation))-->|subclass|E
    X((Expression))-->|subclass|E
    W((Work))--> |subclass|E 

In instance data, you might have:

    flowchart BT
    A[Moby Dick]-->|rdf:type|W
    B[English]-->|expresses|A
    B[English]-->|rdf:type|E
    W((openwemi:Work))
    E((openwemi:Expression))

Both the subject that is a Work and the subject that is an Expression are, by inference, also members of the class Endeavor, but there is no node in the instance data that identifies an Endeavor. Endeavor only exists as an inference:

    flowchart BT
    A[Moby Dick]-->|rdf:type|W-->|subclass|EN1
    B[English]-->|expresses|A
    B[English]-->|rdf:type|E-->|subclass|EN2
    W((openwemi:Work))
    E((openwemi:Expression))
    EN1((Endeavor))
    EN2((Endeavor))

Note that the subjects, which are members of WEMI classes, are each separately subclassed to Endeavor. It would be easy for people to assume that there is a single Endeavor that they are describing, but there is no "thing" that is Endeavor, only a class relationship. In this sense, Endeavor is like owl:Thing - all vocabulary elements are by definition subclassed to owl:Thing but that does not mean that in instance data one is defining a single thing. The concept of class is more ethereal than people generally think of it and I think there is a tendency to view classes as "things" when the only "things" that exist are those encoded in instance data.

First, have I described this correctly? Second, I wonder if we need to make this clear (somehow) in the primer? One idea would be not to introduce Endeavor with the openwemi classes initially, but bring it in after they have been explained and downplay it as "just" for inference.

philbarker commented 6 months ago

We should say in the primer that: " We do not expect implementers to use the Endeavor class. It is used as a convenience for the ontology in order to allow us to talk about all four OpenWEMI classes without enumerating them all.

kcoyle commented 6 months ago

In https://github.com/dcmi/openwemi/pull/101

kcoyle commented 5 months ago

Added to primer; approved Apr 2 meeting