User:Lectrician1/Works2Classes

Wikiproject Books and Wikiproject Music and possibly others use a system of "works" and its sublayer of an "edition" to categorize publications that are reproduced as different versions, translations, etc.

This system has some downsides:

• Data structures are limited to their specific layers/classes determined by their systems (4 for FRBR, 3 for BIBFRAME, 2 for MusicBrainz, etc.)
• These structures are difficult for beginners to understand and often require reading into documentation
• These layers utilize metaclasses, causing bloat
• The layers are just another way to say "class". They group real world objects that have similar traits and are therefore classes. Likewise, they have types/editions/version, or subclasses.
• Properties are required to be duplicated among layers. For example, the author of a book must be on the work and version item.
• exemplar of (P1574) is a copy of instance of (P31) and manifestation of (P1557), edition or translation of (P629) expression of (P6524) are copies of subclass of (P279).

So, my proposal is to replace these standardized layers with classes. Classes solve these downsides:

• Classes can have as many layers as needed to classify/group works derived from general ideas.
• Editors don't need to worry about what specific layers mean. They simply create a layer they want and if someone wants to make a sublayer, they can.
• Class are classes. No metaclasses!
• Classes are classes.
• Subclasses automatically inherit the properties of their parent classes.
• We already have these class-based properties, why don't we use them and not further confuse editors?

Note, there may be some downsides to this as it could possibly get a bit messy.

Feel free to leave comments about it on the Discussion page.

Proposal applications

Music discographies

Current system

Music discographies currently use the layers of release group (Q108346082) and musical release (Q2031291), and optionally the even higher layer release (group) series (Q110940584) to group and describe music releases. This is modeled according to MusicBrainz (Q14005)'s model.

The MusicBrainz wiki describes them as:

"A release group, just as the name suggests, is used to group several different releases into a single logical entity. Every release belongs to one, and only one release group.

Both release groups and releases are "albums" in a general sense, but with an important difference: a release is something you can buy as media such as a CD or a vinyl record, while a release group embraces the overall concept of an album -- it doesn't matter how many CDs or editions/versions it had.

When an artist says "We've released our new album", they're talking about a release group. When their publisher says "This new album gets released next week in Japan and next month in Europe", they're referring to the different releases that belong in the above mentioned release group.

The relationship between musical release (Q2031291) and release group (Q108346082) on Wikidata is described with release of (P9831).

On Wikidata, we make release groups instances of a subclass of release group (Q108346082) like album (Q482994), extended play (Q169930), or single (Q134556) and releases instances of a subclass of musical release (Q2031291) like album release (Q108352648), extended play release (Q108346556), or single release (Q108352496).

Here is an example of current release group and it's releases:

• Taste of Love (Q106797774)instance of (P31)release group (Q108346082)
  • Taste of Love (Q107051335)instance of (P31)digital EP (Q107124972)
  • Taste of Love (In Love Version) (Q107050917)instance of (P31)CD EP (Q66679998)
  • Taste of Love (Fallen Version) (Q107050890)instance of (P31)CD EP (Q66679998)
  • Taste of Love (Taste Version) (Q107050654)instance of (P31)CD EP (Q66679998)

Proposed system

The musical release (Q2031291)-release group (Q108346082)-release (group) series (Q110940584) can be replaced with the class system.

How this will work is every current release group (Q108346082) type will now become subclass of (P279) musical release (Q2031291).

Then if you want to make a "release group", you make an item that is a subclass of (P279) a musical release (Q2031291) type.

Finally, if you want to make a release, you make an item that is a subclass of (P279) the "release group" item.

Example release hierarchy class structure (subitems are subclass of (P279) their parent):

• musical release (Q2031291)
  • mini album (Q107154516)
    • Taste of Love (Q106797774)
      • Taste of Love (Taste Version) (Q107050654)

Pros compared to the current system

• Mostly all users who create instances of album (Q482994) don't know that they're actually creating an instance of a release group (Q108346082) because album (Q482994) is a subclass of (P279) release group (Q108346082). album (Q482994) is named "album" instead of "album release group" because most editors are usually creating release group items and they don't need to know that they are. But because of this abstraction, editors that they ever come across a musical release (Q2031291) item, they won't easily know the difference between it and a release group (Q108346082) and will have to research documentation, mistakenly merge it with the release group item, or misuse it. It is critical that editors understand what they are editing. Otherwise, these problems are bound to occur and it just wastes other editors time explaining the system and fixing mistakes.
• Basically almost all the properties on musical release (Q2031291) items are duplicated from release group (Q108346082) items. For example, look at Taste of Love (Q106797774) and Taste of Love (Taste Version) (Q107050654). They are about the same. Classes automatically "transfer" these properties so adding them would not be required.

Cons compared to the current system

• Linking MusicBrainz releases could become harder.

Music genres

Music genres are modeled by making ever genre an instance of (P31) the music genre (Q188451) metaclass (Q19361238) and subgenres are subclass of (P279) their parent genre.

Music genre is just another way to say "type of music". Therefore, music genres can instead be modeled as classes and they will all be subclasses of music (Q638). EZ PZ.

Books

I'm not exactly sure if we can replace books yet because I'm still waiting and learning how form of creative work (P7937) works. But, I'm confident that work (Q386724) and version, edition or translation (Q3331189) can be modeled with classes instead as they both act as groups that instances share a number of attributes with - thus classifying them as "works".

Current system

Wikiproject books has decided on a system that involves creating a literary work (Q7725634) and a version, edition or translation (Q3331189). This is based off of BIBFRAME/FRBR. These two are related using the has edition or translation (P747) property.

• Harry Potter and the Philosopher's Stone (Q43361)instance of (P31)literary work (Q7725634)
  • Harry Potter and the Philosopher’s Stone (Q58242028)instance of (P31)version, edition or translation (Q3331189)

Proposed system

Current "works" will now become subclass of (P279) current values used with form of creative work (P7937).

Versions/expressions/manifestations will become subclass of (P279) their "work" item.

• Harry Potter and the Philosopher's Stone (Q43361)subclass of (P279)novel (Q8261)
  • Harry Potter and the Philosopher’s Stone (Q58242028)subclass of (P279)Harry Potter and the Philosopher's Stone (Q43361)

Choreographies

Instead of making something a instance of (P31) choreographic work (Q58483088), choreographic works would be subclass of (P279) choreography (Q180856). These items would be merged.