The four W-E-M-I entities all represent the "same thing"

[lagbolt]

Here's my attempt to express the commonality that the four WEMI entities share.

The basic idea is that the four entities are, in a sense, all "Hamlet" in one way or another.

[kcoyle]

Here's one that I did, with Item as the focus. I also did one with Work as the focus - I may need to recreate that. That gives it a kind of a part/whole structure. I also did this one showing that the WEMI entities can be in the same structure: And this one that shows that a MARC record (happily) has data from different WEMI entities: I wonder if we should add any of these to our documentation?

[seanpetiya]

Below is the diagram I have been working on, borrowing some ideas from both your diagrams @lagbolt and @kcoyle.

My thinking here is to also incorporate the Endeavor superclass, and identify Work, Expression, Manifestation and Item as its subclasses (solid border). I am attempting to also illustrate the levels of abstraction and relationships between classes going from idea to perception to physical item (dotted to dashed borders and white to gray --- or increasing concreteness).

[kcoyle]

What occurs to me is this:

from the point of view of an item, or from a manifestation or expression looking toward the work, there is one "thing". It's a single line of relationships.

from the point of view of a work, or from an expression or manifestation looking toward the item, there can be multiple "things" - because there can be more than one "lower" entity.

No, I don't know what this does for us.

[seanpetiya]

@kcoyle I think this speaks to the utility of WEMI, especially for commerce applications. There is one "Let it Be" (the song, the work), but many expressions (versions, takes, remixes?) and manifestations (albums, cassettes, etc.), and of course many, many items (see #68) (e.g. ASIN #B097CKL5BT).

Below is my best, last attempt at modeling OpenWEMI classes and their relationships. I'm also attempting to indicate (in a not overly technical way) that 1) a resource (description?) can embody one or more OpenWEMI classes, 2) may be split across data records (i.e. database tables) or nodes (i.e. graphs), and 3) may be split across data sources (i.e. linked data). The diagramming approach for these examples is inspired by Ronald Murray's implementation of a "FRBR Paper Tool" for diagramming information resources (around slide 205 and beyond) [1]

[1] https://www.slideshare.net/RonMurray/frbr-physics-and-the-world-wide-web

[thadguidry]

My Intro:

Hi! For those that don't know me, I've helped in various capacity with different hats over the years with Schema.org, Linked Data, GLAM, etc. I noticed @philbarker posted about WEMI and thought I'd jump into a few issues and give my take on things. After looking though many issues, this particular one seemed to be the most advantageous one to get my feet wet with providing some larger context and helping folks take a step back (something we often had to do on Schema.org , where we approached things from the bottom-up oftentimes to finally get consensus on new Types and Subtypes from weird Properties we knew we needed. Now on with the show. :-)

My Opinion on this issue:

They don't represent the same thing entirely. Because Event http://purl.org/NET/c4dm/event.owl# or temporal qualities are not being brought into the picture at all; they are hidden in the descriptions and terminology of, in particular, Manifestation and Expression, but also in Endeavor itself. There's the basic LIFECYCLE quality that is missing in the docs thus far. Many have brought this up in the past about FRBR and the lack of the general lifecycle not being represented well or documented. An example:

Using FaBiO, I can illustrate how AGENT might need to be addressed (documented) in WEMI core, just so that EVENT can have a seat at the table.

1. The reason why W-E-M-I each feel the same is that they are all formed from an Event (which is missing completely from the vocabulary currently).

2. The reason why W-E-M-I each feel different somewhat is that each one stems from a different Event subtype. "But what KIND of Event?"

Currently this is hinted at in WEMI's following properties:

• expresses
• manifests
• instantiates
• expressed by

See that problem above? "expresses" and "expressed by" as currently named cause a temporal clash of an Event subtype against Endeavor if we say that W-E-M-I are all formed by an ACTION or EVENT.

Fixes and further discussion

1. So the first fix would be to see where in WEMI does EVENT or ACTION overlay? I think it definitely seems to play well inserted here:

   responsible entity --> (EVENT) --> Endeavor

   but if that's the case, then the 4 properties above need to correlate with Event somehow, I think. I wouldn't do 4 subtypes for each, but only a common subtype. Looking at Endeavor's description "a creation". When you create something, you've done so at a point in time, an Event.

2. ITEM is a funny one, because there is an EVENT that instantiates (creates) an ITEM in theory. But ITEM is the only one that is In Range Of_ = instantiated by. I'm not sure what to think about that currently.

In other words, ITEM is also not included currently in instantiates Range. Why not? An Endeavor could in theory certainly instantiate an ITEM, no? And then that would complete the lifecycle of all 4 W-E-M-I being the output at a point in time from an Endeavor, no?

[kcoyle]

@thadguidry Thanks for the detailed comment. I see two different aspects here:

1. the relationship of the agent to the entity
2. the description of events (performances, news events, etc.)

For 1, we could try to develop very generic relationships between agents and entities, but I worry that they would not be generic enough. We have defined openWEMI so broadly that a relationship like "produces" could be used with many of the entities: an agent produces a particular stage production (openwemi:Expression); an agent produces a book (openwemi:Manifestation); an agent produces a sculpture (possibly openwemi:Item but also possibly openwemi:Work). Because the context and meaning of the entities will be defined in the community vocabulary, it's rather hard to add specific relationships. The FaBiO relationships would not violate anything in openWEMI, but also would be more specific than openWEMI intends to be.

For 2, this builds on the first point, which is that how events as created works would be defined depends on their communities. For some, an event like a performance might be an Expression; for others a performance might be a Work (e.g. a jazz improv performance).

As for Item and instantiates, I'm not sure of your point. An Item can be instantiated by a Work, an Expression, or a Manifestation. Since an Item is an individual, you could have equivalent or sameAs individuals. We did at one point discuss having all of the entities be defined as iterative (a Work of a Work) but that seemed to be a rabbit hole. We went with the "relateds" like "relatedWork", with the idea that a community vocabulary could create relationships like "X was translated from Y" or "A is a copy of B". Would that solve your Item question?

Beyond this, any examples of actual cases "in the wild" are very much welcome because they will help us test the theory behind openWEMI. So feel free to send along what you run into.

[thadguidry]

@kcoyle

1. You might have misunderstood the EVENT thing. I was meaning that when one "produces", that it's an EVENTful Thing. And maybe because of that a superclass of Endeavor might be an Event, but it's more likely the way currently it's modeled would be that an Endeavor HAS A Event. Thoughts?
2. Yes, you have clarified.

A recent Wikidata edit from me, has the concepts of all 4 I think, well, at least 3. https://www.wikidata.org/wiki/Q123717322 <-- the musical work https://www.wikidata.org/wiki/Q123717349 <-- the performance (of the musical work) at the Event

The musical work (by Balfe) went through multiple manifestations (and by that nature, multiple expressions technically)... until it arrived at a final v6.03 that was performed by the orchestra. Geeky...beyond comprehension, but who cares, it's a real example. :-)

(if you click on the references inside those entity (wiki) pages, you will see some actual videos clipped at the moment it shows the sheet music during the performance)

[kcoyle]

openWEMI is not event-based. It should be, however, compatible with event-based vocabularies that wish to use it. Adding the "event" stack would greatly complicate openWEMI. There is no reason to assume that Endeavor "has an event" rather than that an event results in an Endeavor. It's up to the vocabulary.

[kcoyle]

As for "Endeavor has an event" one could view it as "ResponsibleEntity (action) (WEMI class)". So "person writes book" "performer plays music". And this brings up the question of "event vs action", which represents a point of view - some communities might be interested in events (election, production run, tour date) and others may be focused on actions (ran for office, produced, performed). For many of these, the same language statement could refer to either: "writes" could be an action or an event; "performs" ditto; "produces" ditto. But it would be best if event and action properties would be separately defined, and would have separate domains. Schema.org has both Action and Event and there are other vocabularies with topic-specific classes, like odrl:Action and bio:Event.

I take your point that openWEMI has no properties (or "property") that would relate a member of the class openwemi:ResponsibleEntity to any of the other openWEMI classes. I will open a separate issue for that.

[kcoyle]

closing but may use diagrams. make a link to usage board issues.