History talk:Miscellaneous Production Relationship Type/Artwork Proposal

From MusicBrainz Wiki

Discussion

If you're not certain about adding something to the list above, or you need to discuss anything else about this proposal, discuss the item in this section.

Recording unfulfilling ARs

While you wait on the above to be added, please feel free to use SubOptimalCredits to records ARs that aren't able to be fulfilled with current list. -- FrederikSOlesen 09:56, 02 May 2007 (UTC)

Breaking the current "art design/illustration" relationship

I recommend breaking this relationship in two, as the two are not very closely-related (they're even in different subtrees of the hierarchy above) and this seems confusing. The only problem is what to do with the ARs that already use this relationship. I see only a few possibilities, but they don't seem very satisfactory, so maybe someone can suggest something better:

  • Just delete them. Of course, that looses data.
  • (1) Add the new relationships, and leave the old one in a "deprecated" state where it can't be added to new releases. (2) Then auto-add an edit note to all edits that added such relationships, asking the moderator to re-do the edit with the new AR types. (3 - optional) After a while, send a note to subscribers of the artists that still have such ARs asking them to change them. (4) Make a list of still-existing ARs, if there are not lots maybe we can do a "clean-up week" where volunteers can clean up some more. (5) Finally, drop whatever's left :(
  • The "lazy" version: just leave the old version together with the new ones. (And maybe "deprecate" it, so it's not used anymore.) Note that this problem with existing data occurs not only when breaking an existing AR, but also if an existing AR is "reparented" in the hierarchy (unless Robert or somebody goes and whacks the underlying DB tables with some SQL magic) since there is no way to re-parent entries now - they have to be deleted and re-added. @alex

Domains of artwork contribution

It was noted on the mailing list and above that sometimes credits mention "cover art" (or "cover photography", presumably more) but sometimes just "artwork" (or "photography" etc.).

It might be a good idea to add only the functional roles (i.e. "photography", "concept", "artwork", "typography") under the general "artwork AR" category, and have checkboxes for specific areas: "cover", "booklet", "disc", "data track". I have only encountered "cover art" and [generic] "artwork" types, but conceivably there may be more, especially with all the special-deluxe-limited-edition-picture-vinyl-with-extra-bonus-tracks-plus-poster-and-decoder-ring releases that are coming out these days. -- Bogdanb

Use more attributes

There are way too many different AR types above. Using an {artwork} attribute for cover/booklet/disc makes a lot of sense - I tried it on the test server. Things like executive design are also better dealt with as an attribute (if at all). But there are still too many functional roles: "art direction", "design", "layout", "concept", "photography", "illustration", "typography". Maybe the photography/illustration/typography thing could be an attribute? And the difference between "art direction" and "concept" seems blurry, as also for "design" and "layout". Remember, this is MusicBrainz - chopping hairs about the visual artwork is a bit of a reach for this database @alex

  • I agree there are more entries than I'd like. But this is not about splitting hairs on the visual artwork; it's about entering the equivalent of liner notes through ARs. There are reasons we should like to do this very precisely. (Of course, someone may only want a single "artwork" role and be done with it.) And the problem is that real liner notes (those on the booklets) really are this complicated. All the examples above are obtained from CD covers, not invented. The problem with simplifying them a little (as you suggest) is that it becomes complicated to map on-the-cover credits to the ARs --- especially as they're not exactly synonymous. I could give you examples where each is different from the other, which means we loose data by converting them. (Of course, the cover data is not always 100% accurate, but that doesn't mean we should pollute it even more.) My point is that rather than have the editors scratch their heads what to do with what's on the cover, we simply add whatever is usually found (it's not like there are 100 different roles) and let them pick from there. This reduces the problem to only translations -- which can be more accurate if we have more terms available. -- Bogdanb 15:05, 09 May 2007 (UTC) About making photography/illustration/typography attributes, I don't quite see what they would be attributes of. I've only seen them individually (as "...photography by...") on covers, so I don't see how to pick them closer. I'll change the proposal above to allow more attributes, though, after I play a bit with them on my server. -- Bogdanb 15:05, 09 May 2007 (UTC)