User:CallerNo6/sandbox3: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
No edit summary
m (Legoktm moved page User:Caller number six/sandbox3 to User:CallerNo6/sandbox3: Automatically moved page while renaming the user "Caller number six" to "CallerNo6")
 
(6 intermediate revisions by one other user not shown)
Line 1: Line 1:
[[area:]]

=Playing Around With Work Hierarchy=
=Playing Around With Work Hierarchy=


It seems like before we go any further with the CSG or with specific Works-related style discussions, it'd be nice to have an idea of what we can/should ''do'' with Works. Or "thingies".
It seems like before we go any further with the CSG or with specific Works-related style discussions, it'd be nice to have an idea of what we can/should ''do'' with Works. Or "thingies".
[[Image:Works.png|thumb|What did I just do?]]
[[Image:Works.png|thumb|What did I just do?]]
==Preface: Semantics==
==Overview==


"Work" is a misleading term to me. It means, in most contexts, something like "composition". But a "work" as it exists in the database is really more like a "div" in HTML. It's a flexible, re-purpose-able, nestable entity. In short, it's a "[[MusicBrainz_Slang#thingy|thingy]]".
As I see it, there are two "camps" where "works" are concerned. One wants a sensible, uncomplicated list of compositions by a particular artist. The other wants to model lineage and genealogy, showing a complex set of relationships. I'm looking for a way to satisfy both.


To <span id="confuse">confuse</span> matters more, below I list "Work" as one of the possible attribute values of a "Work". That should be undertood as "a composition-level thingy".
In my opinion, a Work-Thingy two essential attributes -- "form" and "type".

==Overview: Two Defining Attributes==

In my opinion, a Work-Thingy would have two essential attributes -- "form" and "type".


===Form===
===Form===
Line 16: Line 22:


*Catalog
*Catalog
*Opus (when used as a "works container"... I realize there's some overlap)
*Opus (which is sometimes used to mean a sort of "work container")
*Collection
*Collection
*Super-Work
*Super-Work
*'''Work''' i.e. "composition"
*'''Work''' i.e. "composition" or "opus"
*Work-part
*Work-part
*Arrangement/Orchestration (if it passes a test for "work-ness")
*Arrangement/Orchestration (if it passes a test for "work-ness")
Line 32: Line 38:


==What is gained?==
==What is gained?==
As I see it, there are two "camps" where "works" are concerned. One wants a sensible, uncomplicated list of compositions by a particular artist. The other wants to model lineage and genealogy, showing a complex set of relationships. Using "work (thingy) types", I'd hope to satisfy both camps.
As I see it, there are two "camps" where "works" are concerned. One wants a sensible, uncomplicated list of compositions by a particular artist. The other wants to create Work Trees that illustrate lineage/genealogy as a complex set of relationships. Using "work (thingy) types", I'd hope to satisfy both camps.

[[#confuse|confused!]]

Latest revision as of 01:57, 29 February 2016

area:

Playing Around With Work Hierarchy

It seems like before we go any further with the CSG or with specific Works-related style discussions, it'd be nice to have an idea of what we can/should do with Works. Or "thingies".

What did I just do?

Preface: Semantics

"Work" is a misleading term to me. It means, in most contexts, something like "composition". But a "work" as it exists in the database is really more like a "div" in HTML. It's a flexible, re-purpose-able, nestable entity. In short, it's a "thingy".

To confuse matters more, below I list "Work" as one of the possible attribute values of a "Work". That should be undertood as "a composition-level thingy".

Overview: Two Defining Attributes

In my opinion, a Work-Thingy would have two essential attributes -- "form" and "type".

Form

What we now call "Work Type" is really a "Work (Thingy) Form". More on forms at wikipedia. This would also include some non-musical forms, such as "poem" and "lecture" maybe?

Type

A "Work (Thingy) Type" would be, in my scheme, a description of how the "thingy" fits into a hierarchy.

  • Catalog
  • Opus (which is sometimes used to mean a sort of "work container")
  • Collection
  • Super-Work
  • Work i.e. "composition" or "opus"
  • Work-part
  • Arrangement/Orchestration (if it passes a test for "work-ness")
  • Version/Variation (if it passes a test for "work-ness")
  • Mashup
  • Re-Mix (if it passes a test for "work-ness")

Strategy

"Work (Thingy) Types" would be linked using (naturally) work-work Relationships (of course). Most types wouldn't display by default on an artists "work list".

My goal would be to do all of this using attributes, relationships and a slight tweak to how work-lists are displayed.

What is gained?

As I see it, there are two "camps" where "works" are concerned. One wants a sensible, uncomplicated list of compositions by a particular artist. The other wants to create Work Trees that illustrate lineage/genealogy as a complex set of relationships. Using "work (thingy) types", I'd hope to satisfy both camps.

confused!