On 13/08/07, Brian Schweitzer <[EMAIL PROTECTED]> wrote:
>
> I spent a lot of time recently going through and examining every AR we
> have.  I found some that seem missing in what they can or can't be used for,
> and some that just make you go "huh?".  I've listed them all below, with
> some suggestions for how we could change/fix things, if everyone agrees that
> some or all of these are a bit wierd and in need of adjustment.
>
> 1) "track is the earliest version of track"
> http://wiki.musicbrainz.org/OtherVersionRelationshipType?highlight=%28earliest%29%7C%28version%29
>
>
> a) First, to piggyback on the recent discussions as to quite what a
> "remaster" actually is, the following is not in agreement:
>
> "The song must have been re-recorded: where the same original source
> tracks are used, the RemasterRelationshipType should be used instead."
>
> This then means that we're using the term "remaster" in one context for
> releases, but in a different context for tracks.  If the same album is
> rereleased with bonus tracks, but not remastered, the most proper AR would
> seem to be "track is the earliest release of track", not "track is a
> remaster of track".
>
> Proposed: Change the wording to "The song must have been re-recorded:
> where the same original source tracks are used, the track-track "Earliest
> Release of AR" should be used instead."
>

yes - change this straight away IMO. i think it must have been a mistake


b) "In line with the DontMakeRelationshipClusters principle, all versions of
> a song should be linked to the earliest released version of the song. For
> example, if a demo version of a song is recorded, then a properly produced
> version which goes out on an album, and then the demo version gets released
> on a "best of" compilation, then the album version "is the earliest version
> of" the compilation version. It doesn't matter when they were recorded, only
> when they were released. This is because the release date is easier to
> verify. "
>
> This makes no sense to me.  We're going to link a demo track, or an
> unmastered (perhaps bootleg) recording of that same recording session to
> just whichever track was released first, because it's easier to find out
> when the album was released than to figure out when the track actually was
> first recorded?  To put this in an extreme case, consider Chinese
> Democracy.  Following the above logic, for any leaked tracks appearing on
> bootlegs, or alternate versions appearing on singles between now and when it
> finally is released, those tracks have no "earliest version" target - they
> may have to wait years until the album is released.  Wouldn't it just be
> logical that the demo recording is the earliest version, no matter what?
> Otherwise you get a "track (released) is the earliest version of track
> (original demo)" situation.
>



Proposed: See #4 for a partial fix, once demos are removed, clarify quite
> what is the earliest version, with consideration that ARs are not required
> (so we can research all we want before creating them), and thus, accuracy
> ought to trump convenience re: "easier to verify".
>

I agree with all this.


> 2) Does the "release is a cover of release" AR actually make sense?  If a
> release really is a complete cover of another release - and I admit, I
> cannot think of any such example - the tracks themselves also are covers of
> the original tracks, and by allowing for this release-based AR, we simply
> segment the covers for that one track into two groups, making it that much
> more difficult to find all the covers (or at least, those in the database)
> by simply looking at the covers rels for that track, where one would assume
> they ought to be.
>
there are quite a lot of entire cover albums by the same artist (ie an
entire track for track cover of an album by another artist). i have seen
them come up - eg, sgt pepper's definitely has a few (perhaps not AR'd up
here, though). if you have a release is cover of release AR, you don't need
track ARs because it is inferred, and indeed, should be inherited down to
the tracks (i have a ticket open for this).

i guess this is the same situation for VA cover albums which cover one
album, thinking about it, and there are 1000s of those.

Proposed: Remove the release-release version of the AR (converting any such
> existing ARs to the track-track ARs)
>

disagree, see above :)

3) We have a "release is a live performance of release" AR, but not a "track
> is a live performance of track".  This falls into the same situation as #2
> above.  I can think of very few situations where release X is a complete
> live performance of release Y - and ONLY of release Y.  I can, however,
> think of tens of thousands of examples where track A is a live performance
> of track B.  Yet we have this AR only at the track level, and not the
> release level.
>
> Proposed: add a track-track "is a live performance of" AR, Remove the
> release-release version of the AR (converting any such existing ARs to the
> track-track ARs)
>

this has some conflict with the 'other version' track AR. ie, a lot of live
versions are re-arranged slightly, especially over time. is it ok to use
both ARs at once? i guess so, but perhaps this needs to be fleshed out with
some examples on the AR page if it goes ahead. i don't mind doing this if
people seem to be in agreement with the principle!

> 4) Proposed: Somewhat avoiding the problem in #1b, and since we have a
> very similar AR in #3, why not add a "track/release is a demo for
> track/release" AR?  This would take all the demos out of consideration for
> "track is the earliest version of track", as there would be a more specific
> and more correct AR to handle those situations, and then we could more
> appropriately consider track-track ARs in terms of which was the "first" in
> a less complicated manner.
>

hmm, well i think this is all about the 'version' and 'release' ARs really
cos a lot of bands end up promoting a demo recording to a full album track.
i think we should just use the normal ARs, and then add a new release type
'demo' (which we've been needing for an age).

5) Oddly, you can set a Creative Commons Download AR for a release and
> track, but not an artist.  With many artists listing whole pages of CC
> downloads, be it at label sites, subpages within artist sites, archive.org,
> etc, there seems to be a decent enough reason why we might also want this AR
> at the artist level.
>
> Proposed: add a artist-url AR to link artists to CC Download pages#
>

i don't agree with this cos a CC license is issued on a bit of media, not on
an entire artists repetoire (unless of course i guess they die!). i don't
think we should pre-empt an artists wishes for future releases

6) Pretty much the entirety of the Misc section of the Track-URL
> relationships - seems a total hodgepodge of "huh?" in here:
> http://musicbrainz.org/edit/relationships/link_types.html?type=track-url
>
> Many of these suffer from the same problem.  If these really do have good
> reason to exist, they perhaps ought to be at the release and/or artist
> level, perhaps also separately as label-URL ARs.  However, most of them
> simply combine two other situations badly, as I see it.  To use the first in
> the list, instead of using the "release X had legal representaion by artist
> Y", then "artist Y has a official homepage at URL Z", we say "track A had
> legal representation by URL Z" - which makes not a whole lot of sense.
>
> a) "track has legal representation by UR:" See above.  Similar to the
> "artist has legal representation by artist" and the release level "album has
> legal representation by artist" ARs, but links the track to a URL instead of
> the artist, unlike the other two AR levels.  Oddly, however, we have no AR
> to link the artist-entire, or the label, to their respective lawyers - only
> a album-artist AR and a track-url AR.
>
> Proposed: get rid of the track-url AR, add a label-artist and
> artist-artist AR for "has legal representation by".
>
> b) "track was booked by URL" : Does this even make sense?  Booking
> normally would, as I understand it, represent "made travel arrangements",
> which has separate ARs, similar to the legal representation situation, at
> the release level ("artist had travel arrangements by artist").
> Additionally, at the track level, again, we're linking to a URL, while at
> the release level linking to an artist.
>
> Proposed: get rid of the track-url AR
>
i think the point of these might be when a website is quoted on the sleeve,
rather than a person/company. i guess you could easily infer the actual
company from these, add that to MBz, then do an 'official homepage' AR but
then it seems a bit of a 'waste' of an artist, and indeed contrary to how
this info is presented on sleeves. i think we could leave this as it is.

> c) "track has artist & repertoire support by URL" - Even in the wiki page
> for this AR, and I quote, "Artist and Repertoire Support: I must confess
> that I don't have any idea what this means. --MatthewExon "  Does anyone?
> http://wiki.musicbrainz.org/MiscellaneousProductionRelationshipType
>
> Proposed: Unless someone can figure out what this is, remove it?
>
doesn't seem like anything that couldn't be represented by [additional] A&R
which we can already do (i think??)

d) "track has creative direction by URL": Same problem as legal
> representation, and badly duplicates/combines the track-artist "track has
> creative direction by artist" AR and "artist has an official homepage at".
>
> Proposed: get rid of the track-url AR
>
> e) "track has art direction by URL"
> f) "track has design/illustration by URL"
> g) "track has graphic design by URL"
> h) "track has {additional} photography by URL"
> i) "track has travel arrangement by URL"
> j) "track has merchandising by URL"
> k) "track was published by URL"
>
> For e through k, same exact issues and commingled redundancy as d.
>

see a couple of answers back - i think our current method is the most
elegant one for such companies.

Proposed: Get rid of them.
>
> 7) "track was recorded by studio at URL": Now this could be a nice AR, if
> we did it right.  Creating a "Recording Location" field, like we did with
> Label, has been suggested a few times as a solution to get rid of
> LiveBootlegStyle - we could have a track-Recording Location AR which would
> be much more useful than this.  However, shorter term, why would we want
> each track to link to a website for a recording studio, if one even exists?
> (Think of jazz recordings from the 1960's - I doubt most, if any, of those
> locations have official pages today.)
>
> Proposed: Create an additional subtype under "Label", "Recording
> Location".  Remove this track-URL AR, and add both a release-label AR and a
> track-label AR, "track/release was recorded at label (recording location)".
> A single date field (either &startdate_y/m/d or &enddate_y/m/d  - or even a
> new just plain &date_y/m/d) could even store the recording date, and we'd be
> also able to then get rid of LiveBootlegStyle and LiveTrackStyle as
> unneeded.  If any such URL exists, it then could be attached to that "label"
> listing using the "has official site at" label-url AR.
>

i'm not sure about this - a) i don't think it's easy/possible to use
free-text strings in ARs, b) i think it would be quite useful to have some
kind of way of seeing all the releases recorded in some particular location
(studio/venue/etc), and a free-text doesn't allow this (unless we make sure
people use the same one...think of the edit notes!).

so yeah i think this requires some new framework to really do it right.
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Reply via email to