monxton | 1 Jul 2012 02:15
Gravatar

Re: RFC: Clarify that work types do not apply to works of popular music

On 25/06/2012 19:48, Kuno Woudt wrote:
> On 25/06/12 20:35, Johannes Weißl wrote:
>> So why not using "Song" for all popular works? It could be the first
>> item on the list or even be selected by default.

What concerns me about this discussion is an unspoken consensus that all 
music is either "classical" or "popular".

It may be OK to shoehorn all "popular" works into "song" type, but it is 
not OK for all non-classical works.
David Hilton | 1 Jul 2012 02:35
Picon
Gravatar

Re: Sampling at the composition/work level

On Sat, Jun 30, 2012 at 12:39 PM, Nicolás Tamargo de Eguren <reosarevok-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Sat, Jun 30, 2012 at 9:35 PM, Nicolás Tamargo de Eguren
<reosarevok-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sat, Jun 30, 2012 at 8:26 PM, Philip Jägenstedt <philip-0vxbLIdyC5Qdnm+yROfE0A@public.gmane.org> wrote:
>> http://musicbrainz.org/edit/18155855
>>
>> In short, I know of at least 3 works where a well-known piece of music
>> was "sampled" in a new work:
>>
>> http://musicbrainz.org/work/faacf69c-a008-47bf-a705-4099219c35af
>> http://musicbrainz.org/work/1a5edc0e-a2eb-40b3-92a9-78d15fb536d4
>> http://musicbrainz.org/work/ed1600ee-46f0-4e5d-adc1-03341d515287
>>
>> The "version of" work-work AR seems inappropriate, so what to do?
>
> I don't really see a big issue with listing Beethoven as composer,
> although I know monxton and I won't agree on this one.

On second thought I guess that doesn't really solve the issue anyway.
I would love more options to link works, including "transcription" for
classical and probably something like what you mention - although I'm
not too sure how I would call it since I don't think "sampling" is a
correct name.

"Borrows material from' wouldn't be a bad description, though it may be a bit too broad...

David
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Philip Jägenstedt | 1 Jul 2012 09:34
Gravatar

Re: Sampling at the composition/work level

On Sat, Jun 30, 2012 at 10:56 PM, monxton
<musicbrainz <at> jordan-maynard.org> wrote:
> On 30/06/2012 19:39, Nicolás Tamargo de Eguren wrote:
>> On Sat, Jun 30, 2012 at 9:35 PM, Nicolás Tamargo de Eguren
>> <reosarevok <at> gmail.com>  wrote:
>>>
>>> I don't really see a big issue with listing Beethoven as composer,
>>> although I know monxton and I won't agree on this one.
>
> As I said in the edit, there are at least two reasons why I don't like
> it. First, because Beethoven obviously did not compose this this work.
> But even if it was "closer" to Beethoven's work than it is, I dislike to
> see these mashups among the list of works that Beethoven composed - it
> just seems wrong, and I think it discredits the database.
>
> In any case, a work-work relationship gives more information, because it
> tells you which of Beethoven's works is quoted. This is much more useful
> than just setting Beethoven as the composer.

Note that Beethoven is listed as a composer on the same level as 陳輝陽
in the music video (http://www.youtube.com/watch?v=tR20mI5LxSU) which
says 作曲: 陳輝陽/貝多芬. I don't know what the booklet says, but it would be
a bit weird if the two composers couldn't be deduced without ambiguity
from the data we have.

If we can agree on the work-work AR perhaps the rest will fall into
place, but how broad should it be. The wording I used in the
annotations was "includes elements of" and "incorporates part of". I
suppose that the AR we invent should also be used for Beethoven's
variations of Mozart compositions, how would someone with a clue about
classical phrase the relationship between two such works?

--

-- 
Philip Jägenstedt

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style <at> lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Rachel Dwight | 1 Jul 2012 09:41
Picon

Re: Sampling at the composition/work level


On Jul 1, 2012, at 2:34 AM, Philip Jägenstedt wrote:

> On Sat, Jun 30, 2012 at 10:56 PM, monxton
> <musicbrainz <at> jordan-maynard.org> wrote:
>> On 30/06/2012 19:39, Nicolás Tamargo de Eguren wrote:
>>> On Sat, Jun 30, 2012 at 9:35 PM, Nicolás Tamargo de Eguren
>>> <reosarevok <at> gmail.com>  wrote:
>>>> 
>>>> I don't really see a big issue with listing Beethoven as composer,
>>>> although I know monxton and I won't agree on this one.
>> 
>> As I said in the edit, there are at least two reasons why I don't like
>> it. First, because Beethoven obviously did not compose this this work.
>> But even if it was "closer" to Beethoven's work than it is, I dislike to
>> see these mashups among the list of works that Beethoven composed - it
>> just seems wrong, and I think it discredits the database.
>> 
>> In any case, a work-work relationship gives more information, because it
>> tells you which of Beethoven's works is quoted. This is much more useful
>> than just setting Beethoven as the composer.
> 
> Note that Beethoven is listed as a composer on the same level as 陳輝陽
> in the music video (http://www.youtube.com/watch?v=tR20mI5LxSU) which
> says 作曲: 陳輝陽/貝多芬. I don't know what the booklet says, but it would be
> a bit weird if the two composers couldn't be deduced without ambiguity
> from the data we have.
> 
> If we can agree on the work-work AR perhaps the rest will fall into
> place, but how broad should it be. The wording I used in the
> annotations was "includes elements of" and "incorporates part of". I
> suppose that the AR we invent should also be used for Beethoven's
> variations of Mozart compositions, how would someone with a clue about
> classical phrase the relationship between two such works?
> 
> -- 
> Philip Jägenstedt

It's good you mentioned that. We should have some kind of marker for "original" composers in the case of
derivative works. I've mostly run into this problem with translated works, whereas we have an AR that
stipulates a translator but we have nothing besides a normal AR for the original lyricist. Perhaps we
could add something to the work-to-work relationship that lists the original artist credits like a
work-to-recording relationship has?

> _______________________________________________
> MusicBrainz-style mailing list
> MusicBrainz-style <at> lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style <at> lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Nicolás Tamargo de Eguren | 1 Jul 2012 17:05
Picon
Gravatar

Series support discussion

Hi! Sending this here mainly because it has more active users than
mb-users anyway...

So, in October we'll have the next schema change release, and I would
like to get series support into it (or, failing that, into next May's
release). For that, we'd need a new entity (which devs seem happy
with) and an interface, and to decide exactly what we want our series
support to be. So, let's discuss that!

My current idea is a pretty simple thing: a series has an MBID, a
name, and a list of things (releases or recordings [1]) in an order.
Is there anything else they need?

UI issues are:

How to display them?
My current answer is "just a list, with all the stuff for editing
shown only when in the /edit URL like for other entities"

How to edit a series?
My current answer is "making the edit series page a series of search
fields, where you can both search for the stuff inline or (probably
easier) just paste the URLs in"

How to add new stuff to a series?
The main options are "Add at the bottom" (like for tracklists) or
"Insert button after every line". The former is cleaner, the latter
might be more useful - but is it worth it? Or will we be adding stuff
in order anyway in most cases?

How to change the order?
Drag and drop is hard, but arrows can be a pain if you can only add
stuff in the end to begin with. Of course, it would be less of an
issue if we decide to allow to add stuff at every position. Starting
with arrows is probably simpler, with other options added
post-schema-change if needed.

How to remove stuff from a series?
A simple X button should do, like in tracklists, I'd say.

So, what have I forgotten, what sounds wrong, etc? :)

[1]  for video series, like http://vimeo.com/album/1656956 and
standalone-recording podcast series.

--

-- 
Nicolás Tamargo de Eguren
Philip Jägenstedt | 1 Jul 2012 18:34
Gravatar

Re: Series support discussion

On Sun, Jul 1, 2012 at 5:05 PM, Nicolás Tamargo de Eguren
<reosarevok@...> wrote:
> Hi! Sending this here mainly because it has more active users than
> mb-users anyway...
>
> So, in October we'll have the next schema change release, and I would
> like to get series support into it (or, failing that, into next May's
> release). For that, we'd need a new entity (which devs seem happy
> with) and an interface, and to decide exactly what we want our series
> support to be. So, let's discuss that!
>
> My current idea is a pretty simple thing: a series has an MBID, a
> name, and a list of things (releases or recordings [1]) in an order.
> Is there anything else they need?
>
> UI issues are:
>
> How to display them?
> My current answer is "just a list, with all the stuff for editing
> shown only when in the /edit URL like for other entities"
>
> How to edit a series?
> My current answer is "making the edit series page a series of search
> fields, where you can both search for the stuff inline or (probably
> easier) just paste the URLs in"
>
> How to add new stuff to a series?
> The main options are "Add at the bottom" (like for tracklists) or
> "Insert button after every line". The former is cleaner, the latter
> might be more useful - but is it worth it? Or will we be adding stuff
> in order anyway in most cases?
>
> How to change the order?
> Drag and drop is hard, but arrows can be a pain if you can only add
> stuff in the end to begin with. Of course, it would be less of an
> issue if we decide to allow to add stuff at every position. Starting
> with arrows is probably simpler, with other options added
> post-schema-change if needed.
>
> How to remove stuff from a series?
> A simple X button should do, like in tracklists, I'd say.
>
>
> So, what have I forgotten, what sounds wrong, etc? :)
>
> [1]  for video series, like http://vimeo.com/album/1656956 and
> standalone-recording podcast series.

What's the use case? Do series correspond to some real-world concept
with official standing, or is it for users to make lists of favorite
songs? Can one make lists of any entity, or just recordings and
releases?

--

-- 
Philip Jägenstedt
Nicolás Tamargo de Eguren | 1 Jul 2012 18:51
Picon
Gravatar

Re: Series support discussion

On Sun, Jul 1, 2012 at 7:34 PM, Philip Jägenstedt <philip@...> wrote:
> On Sun, Jul 1, 2012 at 5:05 PM, Nicolás Tamargo de Eguren
> <reosarevok@...> wrote:
>> Hi! Sending this here mainly because it has more active users than
>> mb-users anyway...
>>
>> So, in October we'll have the next schema change release, and I would
>> like to get series support into it (or, failing that, into next May's
>> release). For that, we'd need a new entity (which devs seem happy
>> with) and an interface, and to decide exactly what we want our series
>> support to be. So, let's discuss that!
>>
>> My current idea is a pretty simple thing: a series has an MBID, a
>> name, and a list of things (releases or recordings [1]) in an order.
>> Is there anything else they need?
>>
>> UI issues are:
>>
>> How to display them?
>> My current answer is "just a list, with all the stuff for editing
>> shown only when in the /edit URL like for other entities"
>>
>> How to edit a series?
>> My current answer is "making the edit series page a series of search
>> fields, where you can both search for the stuff inline or (probably
>> easier) just paste the URLs in"
>>
>> How to add new stuff to a series?
>> The main options are "Add at the bottom" (like for tracklists) or
>> "Insert button after every line". The former is cleaner, the latter
>> might be more useful - but is it worth it? Or will we be adding stuff
>> in order anyway in most cases?
>>
>> How to change the order?
>> Drag and drop is hard, but arrows can be a pain if you can only add
>> stuff in the end to begin with. Of course, it would be less of an
>> issue if we decide to allow to add stuff at every position. Starting
>> with arrows is probably simpler, with other options added
>> post-schema-change if needed.
>>
>> How to remove stuff from a series?
>> A simple X button should do, like in tracklists, I'd say.
>>
>>
>> So, what have I forgotten, what sounds wrong, etc? :)
>>
>> [1]  for video series, like http://vimeo.com/album/1656956 and
>> standalone-recording podcast series.
>
> What's the use case? Do series correspond to some real-world concept
> with official standing, or is it for users to make lists of favorite
> songs? Can one make lists of any entity, or just recordings and
> releases?

http://wiki.musicbrainz.org/Series is the basic use case - same reason
as why a "part of series" relationship was considered before NGS. For
user lists, they can have public collections - dunno if those allow
recordings right now but if not they probably should anyway.

> --
> Philip Jägenstedt
>
> _______________________________________________
> MusicBrainz-style mailing list
> MusicBrainz-style@...
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

--

-- 
Nicolás Tamargo de Eguren
caller#6 | 1 Jul 2012 20:15
Picon
Favicon
Gravatar

Re: Series support discussion

On 07/01/2012 08:05 AM, Nicolás Tamargo de Eguren wrote:
> Hi! Sending this here mainly because it has more active users than
> mb-users anyway...
>
> So, in October we'll have the next schema change release, and I would
> like to get series support into it (or, failing that, into next May's
> release). For that, we'd need a new entity (which devs seem happy
> with) and an interface, and to decide exactly what we want our series
> support to be. So, let's discuss that!
>
> My current idea is a pretty simple thing: a series has an MBID, a
> name, and a list of things (releases or recordings [1]) in an order.
> Is there anything else they need?
I'd imagined a series would have

     * MBID
     * Name
     * Annotation
     * Maybe start/end dates derived from the first/last known releases?
     * Relationships
         ** Label (one or more (I /think/ I've seen a series that spans 
several small labels but I could be mistaken))
         ** Parts (release, release group, tracks or whatever), with 
attribute:
             *** Ordinality: some series have explicit orders, the rest 
would be determined by what? Cat# or release date?
         ** Images (sticker or logo)
         ** Artist, with attributes:
             *** Recording Artist
             *** Other (producer, engineer etc) (example: 
http://www.discogs.com/label/RVG+Edition )

I'd imagined series would display (and be edited) pretty much like 
labels. Your UI sounds better, of course.

Alex / caller#6
caller#6 | 1 Jul 2012 20:50
Picon
Favicon
Gravatar

Re: Series support discussion

On 07/01/2012 11:15 AM, caller#6 wrote:
> I'd imagined a series would have
>
>       * MBID
>       * Name
>       * Annotation
>       * Maybe start/end dates derived from the first/last known releases?
>       * Relationships
>           ** Label (one or more (I /think/ I've seen a series that spans
> several small labels but I could be mistaken))
>           ** Parts (release, release group, tracks or whatever), with
> attribute:
>               *** Ordinality: some series have explicit orders, the rest
> would be determined by what? Cat# or release date?
>           ** Images (sticker or logo)
>           ** Artist, with attributes:
>               *** Recording Artist
>               *** Other (producer, engineer etc) (example:
> http://www.discogs.com/label/RVG+Edition )
>

Oops, under relationships I forgot

** URLs
practik | 2 Jul 2012 09:16
Picon
Favicon

Re: Sampling at the composition/work level


Philip Jägenstedt wrote
> 
> On Sat, Jun 30, 2012 at 10:56 PM, monxton wrote:
>> In any case, a work-work relationship gives more information, because it
>> tells you which of Beethoven's works is quoted. This is much more useful
>> than just setting Beethoven as the composer.
> 
> If we can agree on the work-work AR perhaps the rest will fall into
> place, but how broad should it be. The wording I used in the
> annotations was "includes elements of" and "incorporates part of". I
> suppose that the AR we invent should also be used for Beethoven's
> variations of Mozart compositions, how would someone with a clue about
> classical phrase the relationship between two such works?
> 

I've had the idea of such a work-work relationship on my AR wish list for a
while now.  A pretty common term I've seen in the classical context is
"quotation,"* but I personally would prefer to see us use a broader term lke
"adaptation."  To me, quotation implies a "straight" reproduction of a
section of the original work, without changing it, but I feel like lyricists
and composers often rework the original material, at least in the pop
context.

An example:  The line "And everything depends upon how near you sleep to
me," from Leonard Cohen's song "Take This Longing," is quoted in "Hand in
Glove" by The Smiths, except the word "sleep" is replaced by "stand."  It's
not quotation in the strictest sense of the word, but it's still clearly a
reference to Cohen.  Semantically, "adaptation" would encompass this sort of
thing nicely.

And in fact, we have a suggested phrasing for such a relationship, courtesy
of caller#6: "[work] includes [lyrics|music] adapted from [work]".**

As for how broad to make it, I'd suggest using it only for works that
incorporate parts of other works, and not for works that are themselves
adaptations of other works, since we can use the "version of" relationship
for that.  And I'd say we shouldn't use it for medleys, although it would
technically apply to them, since we have the work-work medley relationship
for those.

Patrick

* http://en.wikipedia.org/wiki/Musical_quotation
** See http://musicbrainz.org/edit/17141710 for context.

--
View this message in context: http://musicbrainz.1054305.n4.nabble.com/Sampling-at-the-composition-work-level-tp4637121p4637163.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style <at> lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Gmane