#musicbrainz-devel

/

      • brianfreud
        I think we're all on the same page :D
      • 2010-03-24 08320, 2010

      • luks
        I'd still like to use the terminology Cover Version and Remix for popular music
      • 2010-03-24 08333, 2010

      • luks
        I think it's not that bad to bring the terminology as close to the target genre as possible
      • 2010-03-24 08355, 2010

      • luks
        if there is different terminology in different genres, use different terminology
      • 2010-03-24 08308, 2010

      • brianfreud
        That was my point... There isn't any such concept, though, at the compositional data level, as "cover", only derivative works. To 'cover' some song involves a performance action, hence its a performance level data. That is true regardless of genre.
      • 2010-03-24 08331, 2010

      • brianfreud
        a 'cover' is even defined something like 'the performance of a song made famous by someone else'
      • 2010-03-24 08338, 2010

      • luks
        yes of course
      • 2010-03-24 08349, 2010

      • luks
        but if you think of works as songs then Cover makes sense
      • 2010-03-24 08338, 2010

      • luks
        that breaks for electronic music done completely on computers
      • 2010-03-24 08353, 2010

      • luks
        as there is usually no separation between composition, arrangement and performance
      • 2010-03-24 08310, 2010

      • luks
        well
      • 2010-03-24 08319, 2010

      • luks
        there is
      • 2010-03-24 08326, 2010

      • luks
        but there is no explicit performance
      • 2010-03-24 08335, 2010

      • luks
        btw, normally when I say something like 'that cover of X by Y' I refer to the arrangement, not a specific performance
      • 2010-03-24 08341, 2010

      • luks
        so I think the terminology is not that wrong
      • 2010-03-24 08357, 2010

      • luks
        but it can be english issue :)
      • 2010-03-24 08304, 2010

      • brianfreud
        lol
      • 2010-03-24 08338, 2010

      • brianfreud
        I get what you mean; I just see it as the inevitable inferrence from a type of intersection between work and track
      • 2010-03-24 08311, 2010

      • brianfreud
        what I wouldn't want to see, though, is someone then misunderstand what you mean, and add a new work every time someone covers a song, even if it is unchanged/reduced/etc. Then we just end up with a list of songs played by some artist,, where that *should* (imho) be linked back to the same original song, not some new song linked by 1+ levels of "work is a cover version of work"
      • 2010-03-24 08358, 2010

      • brianfreud
        murdos: ping?
      • 2010-03-24 08315, 2010

      • luks
        I think we don't have to worry about that :)
      • 2010-03-24 08335, 2010

      • luks
        we will need to ask people to *add* works, not the other way around
      • 2010-03-24 08318, 2010

      • brianfreud
        :P
      • 2010-03-24 08308, 2010

      • luks
        there will be huge confusing about recordings too
      • 2010-03-24 08315, 2010

      • luks
        what to merge and what not
      • 2010-03-24 08328, 2010

      • luks
        *confusion
      • 2010-03-24 08312, 2010

      • brianfreud
        too true
      • 2010-03-24 08323, 2010

      • navap
        Don't worry, there will probably be a hastily written unofficial guideline the day before the server launch - just like what happened to the release groups guideline :p
      • 2010-03-24 08339, 2010

      • brianfreud is REALLY happy to see murdos is still active on MBS-631
      • 2010-03-24 08303, 2010

      • brianfreud
        navap: or the user tags guideline that somehow just died, and was axed today? :D
      • 2010-03-24 08341, 2010

      • navap
        You can't screw up a tag, for numerous different reasons.
      • 2010-03-24 08356, 2010

      • luks
        well, you can :)
      • 2010-03-24 08328, 2010

      • brianfreud
        lol
      • 2010-03-24 08328, 2010

      • luks
      • 2010-03-24 08344, 2010

      • luks
        that's why I call screwed up tags :P
      • 2010-03-24 08346, 2010

      • navap
        luks: lol okay, yeah that guy screwed it up bad.
      • 2010-03-24 08307, 2010

      • brianfreud
        navap: much as it worked, I really think this one is hacky: http://musicbrainz.org/show/release/?mbid=c182867…
      • 2010-03-24 08323, 2010

      • navap
        If you referring to the tag usage, I disagree. I think folksonomy tags are meant to be undefined and left to the user to define when and where to use them.
      • 2010-03-24 08330, 2010

      • luks
        yeah
      • 2010-03-24 08349, 2010

      • luks
        you can do whatever you want with tags
      • 2010-03-24 08354, 2010

      • luks
        but "rock_pop rock_rock_pop rock_rock_pop rock_rock" is just stupid
      • 2010-03-24 08311, 2010

      • navap
        That's a "special case" done by a "special person" :p
      • 2010-03-24 08341, 2010

      • navap
        And it really only becomes a problem when searching for tags, which can easily be fixed by tweaking the search server.
      • 2010-03-24 08349, 2010

      • brianfreud pushes effort to get rock_rock_rock_rock_rock_rock_rock into the top 10 tags
      • 2010-03-24 08351, 2010

      • aCiD2
        qlol
      • 2010-03-24 08331, 2010

      • brianfreud
        Dumb question, maybe, but re: MBS-221, why should the Entity:URL even *have* to know the linktype?
      • 2010-03-24 08331, 2010

      • aCiD2
        hrm, those are interesting tags
      • 2010-03-24 08350, 2010

      • aCiD2
        brianfreud: it doesn't, that's why I left my comment
      • 2010-03-24 08353, 2010

      • aCiD2
        if you're on about the review
      • 2010-03-24 08303, 2010

      • brianfreud
        yeah
      • 2010-03-24 08328, 2010

      • brianfreud
        if the prettyname is just the pagename from the URL (perhaps then cleaned up by a post prettyname parser), I don't see why it should care why link type the URL represents
      • 2010-03-24 08333, 2010

      • aCiD2
        it doesn't
      • 2010-03-24 08349, 2010

      • aCiD2
        it's just using the link type as warp did is an easy way. but subclassing as I said is a bit more flexible
      • 2010-03-24 08316, 2010

      • brianfreud
        yeah
      • 2010-03-24 08321, 2010

      • aCiD2
        it's not a case of using a regex and a parser, that's just as bad as the linktype solution
      • 2010-03-24 08346, 2010

      • warp
        aCiD2: I just submitted a new review in case you haven't seen that yet.
      • 2010-03-24 08348, 2010

      • brianfreud
        I was thinking url.url would populate url.pagename, which could then be handed to that subclassed handler to get url.prettyname
      • 2010-03-24 08355, 2010

      • aCiD2
        oo, i just got back from dinner
      • 2010-03-24 08357, 2010

      • aCiD2
        i'll check it out
      • 2010-03-24 08307, 2010

      • aCiD2
        brianfreud: sure, if you assume that's the only way you'll ever want to do it
      • 2010-03-24 08319, 2010

      • brianfreud
        well, that's why I was separating prettyname and pagename
      • 2010-03-24 08322, 2010

      • aCiD2
        but I can see future cases of something like idmb.com/<foo> display as IMDB: Film Name
      • 2010-03-24 08328, 2010

      • warp
        aCiD2: it's still ugly IMO, but there now is an URL::Wikipedia
      • 2010-03-24 08329, 2010

      • aCiD2
        a parser can't do that
      • 2010-03-24 08322, 2010

      • aCiD2
        why the changes to link_entity?
      • 2010-03-24 08332, 2010

      • aCiD2
        actually nvm, that's much nicer :)
      • 2010-03-24 08334, 2010

      • brianfreud wonders how hard it would be to add an optional date field and optional generic string field to URL AR handling
      • 2010-03-24 08343, 2010

      • warp
        aCiD2: type.search doesn't match subtypes of URL::
      • 2010-03-24 08355, 2010

      • warp
        or children or whatever. them things.
      • 2010-03-24 08358, 2010

      • warp
        :)
      • 2010-03-24 08359, 2010

      • aCiD2
        lol
      • 2010-03-24 08323, 2010

      • aCiD2
        hrm, we shouldn't need a data object for this...
      • 2010-03-24 08345, 2010

      • brianfreud
        warp: I'd been thinking something kind of like what you're doing... http://wiki.musicbrainz.org/User:BrianSchweitzer/… (never proposed) see #s 1 - 6
      • 2010-03-24 08309, 2010

      • aCiD2
        of course, I don't see any other way yet - but this is a bit ickier than I first imagined it to be
      • 2010-03-24 08330, 2010

      • aCiD2
        I don't think linktype_to_model belongs in Data::Utils
      • 2010-03-24 08345, 2010

      • aCiD2
        that belongs in Data::Relationship probably
      • 2010-03-24 08349, 2010

      • warp
        ah, right.
      • 2010-03-24 08352, 2010

      • aCiD2
        Actually
      • 2010-03-24 08309, 2010

      • aCiD2
        We should probably have a URL factory, and that works out what type of URL subclass to use based on some sort of regex on the URL
      • 2010-03-24 08316, 2010

      • aCiD2
        god damnit, someone give me a java job
      • 2010-03-24 08326, 2010

      • warp
        I like factories.
      • 2010-03-24 08329, 2010

      • aCiD2
        :)
      • 2010-03-24 08330, 2010

      • warp
        they make things.
      • 2010-03-24 08347, 2010

      • aCiD2
        can you make it an enterprise abstract factory factory factory?
      • 2010-03-24 08305, 2010

      • warp
        aCiD2: the good thing about a factory would be that the linktype doesn't need to be passed around
      • 2010-03-24 08311, 2010

      • aCiD2
        si
      • 2010-03-24 08323, 2010

      • aCiD2
        plus it works in the case when you don't even have a link type (like url/<gid>)
      • 2010-03-24 08336, 2010

      • warp
        aCiD2: but having a big switch statement dropping through dozens of regexes to find the correct entity sounds pretty bad too.
      • 2010-03-24 08308, 2010

      • aCiD2
        so have that be dynamic. The factory can load everything in the URL:: namespace with Module::Pluggable::Object, and each URL::* object can store the regex
      • 2010-03-24 08327, 2010

      • warp
        (or they register themselves and the factory tries them all)
      • 2010-03-24 08336, 2010

      • aCiD2
        the url factory can then cache that in a Map[RegexRef, ClassName]
      • 2010-03-24 08340, 2010

      • luks
        it's one, exactly one regex :)
      • 2010-03-24 08347, 2010

      • luks
        not a few dozens
      • 2010-03-24 08304, 2010

      • luks
        I wouldn't spend two days on something like this
      • 2010-03-24 08308, 2010

      • warp
        luks: now. yes. but I expect we'll add amazon, imdb, and many more in the future.
      • 2010-03-24 08315, 2010

      • warp
        luks: true.
      • 2010-03-24 08323, 2010

      • luks
        only I have nothing else to do
      • 2010-03-24 08329, 2010

      • luks
        which I guess isn't the case
      • 2010-03-24 08322, 2010

      • luks
        you wanted to go agile? YAGNI
      • 2010-03-24 08347, 2010

      • aCiD2
        yagni doesn't mean use a bad design
      • 2010-03-24 08353, 2010

      • aCiD2
        a url should not depend on a link type to have a pretty name
      • 2010-03-24 08333, 2010

      • luks
        I totally support good design
      • 2010-03-24 08346, 2010

      • aCiD2
        so the switch in the url factory would suffice in this case and when that gets unwieldy then we stick module::pluggable in and make it a bit more dynmaci
      • 2010-03-24 08347, 2010

      • luks
        but if I have lots of more important things to do
      • 2010-03-24 08354, 2010

      • luks
        a single if will not kill me
      • 2010-03-24 08357, 2010

      • warp
        aCiD2: anyway, do you have time / interest in taking this over? I'd rather not spend more time on this ticket.
      • 2010-03-24 08302, 2010

      • aCiD2
        sure
      • 2010-03-24 08316, 2010

      • warp
        yay. I'll assign the ticket to you then. thanks!
      • 2010-03-24 08318, 2010

      • aCiD2
        push that branch out and reassign the ticket to me with a comment when you get a chance
      • 2010-03-24 08324, 2010

      • warp
        will do.
      • 2010-03-24 08341, 2010

      • aCiD2 goes back to wondering why this migrated edit type think the release is in a completely different release group
      • 2010-03-24 08301, 2010

      • brianfreud
        it's lonely
      • 2010-03-24 08316, 2010

      • aCiD2
        if it's lonely it should go to mozart, not some random NAT release group
      • 2010-03-24 08320, 2010

      • aCiD2
        :P
      • 2010-03-24 08326, 2010

      • navap
        haha
      • 2010-03-24 08301, 2010

      • aCiD2
        luks: a MOD_ADD_RELEASE edit has the added release in row_id. This could change after ngs-merge-releases - but surely I should be able to resolve the correct ID through tmp_merge_release, right?
      • 2010-03-24 08314, 2010

      • luks
        yes
      • 2010-03-24 08326, 2010

      • luks
        row_id goes to edit_release
      • 2010-03-24 08343, 2010

      • luks
        it's used for looking up edits
      • 2010-03-24 08321, 2010

      • luks
        maybe there were bugs and the row_ids will not resolve
      • 2010-03-24 08330, 2010

      • luks
        some of them
      • 2010-03-24 08344, 2010

      • warp
        lol
      • 2010-03-24 08358, 2010

      • aCiD2
        hrm, then I don't get why SELECT release_group FROM release WHERE id IN (SELECT new_rel FROM tmp_release_merge WHERE id = <old_id>) is giving the wrong release group
      • 2010-03-24 08319, 2010

      • aCiD2
        I've confirmed <old_id> to be the correct row ID on the old database (select * from album where id=<old_id> gives the correct release)
      • 2010-03-24 08321, 2010

      • luks
        is the release group totally wrong or something possibly related?
      • 2010-03-24 08324, 2010

      • aCiD2
        totally wrong
      • 2010-03-24 08347, 2010

      • aCiD2
      • 2010-03-24 08355, 2010

      • aCiD2
      • 2010-03-24 08307, 2010

      • aCiD2
      • 2010-03-24 08315, 2010

      • luks
        I don't know
      • 2010-03-24 08323, 2010

      • aCiD2
        I think it's because the correct release group was merged later
      • 2010-03-24 08329, 2010

      • aCiD2 keeps poking
      • 2010-03-24 08354, 2010

      • luks
        which is why I asked if they can be related
      • 2010-03-24 08307, 2010

      • luks
        check the result of the subselect first
      • 2010-03-24 08324, 2010

      • aCiD2
        that's empty, so I just use <old_id> (that was pseudo sql)
      • 2010-03-24 08321, 2010

      • luks
        I think tmp_release_merge are actually release event IDs
      • 2010-03-24 08336, 2010

      • aCiD2
        ah..
      • 2010-03-24 08337, 2010

      • brianfreud
        acid2: Re MBS-612; For release-URL and http://www.imdb.com*, has IMDb page at is prob a lot more likely than the samples from IMDb AR; otherwise, looks good
      • 2010-03-24 08341, 2010

      • luks
        my memory is really bad
      • 2010-03-24 08354, 2010

      • luks
        I don't remember how does the upgrade process work
      • 2010-03-24 08326, 2010

      • aCiD2
        brianfreud: oh, that was just a random example - that probably won't ever happen as it requires querying IMDB too and caching it somewhere so it's more work
      • 2010-03-24 08332, 2010

      • aCiD2
        though it'd be nice to have :)
      • 2010-03-24 08311, 2010

      • brianfreud
        no, I mean, I was just testing that AR
      • 2010-03-24 08322, 2010

      • aCiD2
        oh, my bad
      • 2010-03-24 08341, 2010

      • aCiD2
        i just copy and pasted that too :)
      • 2010-03-24 08342, 2010

      • brianfreud
      • 2010-03-24 08341, 2010

      • aCiD2
        i guess that's the JS getting confused, I dunno how that actually works though
      • 2010-03-24 08351, 2010

      • brianfreud
        no idea
      • 2010-03-24 08355, 2010

      • warp
        js? file bugs! I fix!
      • 2010-03-24 08302, 2010

      • brianfreud
        mason, no tix :D