I'd still like to use the terminology Cover Version and Remix for popular music
I think it's not that bad to bring the terminology as close to the target genre as possible
if there is different terminology in different genres, use different terminology
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.
a 'cover' is even defined something like 'the performance of a song made famous by someone else'
luks
yes of course
but if you think of works as songs then Cover makes sense
that breaks for electronic music done completely on computers
as there is usually no separation between composition, arrangement and performance
well
there is
but there is no explicit performance
btw, normally when I say something like 'that cover of X by Y' I refer to the arrangement, not a specific performance
so I think the terminology is not that wrong
but it can be english issue :)
brianfreud
lol
I get what you mean; I just see it as the inevitable inferrence from a type of intersection between work and track
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"
murdos: ping?
luks
I think we don't have to worry about that :)
we will need to ask people to *add* works, not the other way around
brianfreud
:P
luks
there will be huge confusing about recordings too
what to merge and what not
*confusion
brianfreud
too true
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
brianfreud is REALLY happy to see murdos is still active on MBS-631
brianfreud
navap: or the user tags guideline that somehow just died, and was axed today? :D
navap
You can't screw up a tag, for numerous different reasons.
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.
luks
yeah
you can do whatever you want with tags
but "rock_pop rock_rock_pop rock_rock_pop rock_rock" is just stupid
navap
That's a "special case" done by a "special person" :p
And it really only becomes a problem when searching for tags, which can easily be fixed by tweaking the search server.
brianfreud pushes effort to get rock_rock_rock_rock_rock_rock_rock into the top 10 tags
aCiD2
qlol
brianfreud
Dumb question, maybe, but re: MBS-221, why should the Entity:URL even *have* to know the linktype?
aCiD2
hrm, those are interesting tags
brianfreud: it doesn't, that's why I left my comment
if you're on about the review
brianfreud
yeah
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
aCiD2
it doesn't
it's just using the link type as warp did is an easy way. but subclassing as I said is a bit more flexible
brianfreud
yeah
aCiD2
it's not a case of using a regex and a parser, that's just as bad as the linktype solution
warp
aCiD2: I just submitted a new review in case you haven't seen that yet.
brianfreud
I was thinking url.url would populate url.pagename, which could then be handed to that subclassed handler to get url.prettyname
aCiD2
oo, i just got back from dinner
i'll check it out
brianfreud: sure, if you assume that's the only way you'll ever want to do it
brianfreud
well, that's why I was separating prettyname and pagename
aCiD2
but I can see future cases of something like idmb.com/<foo>; display as IMDB: Film Name
warp
aCiD2: it's still ugly IMO, but there now is an URL::Wikipedia
aCiD2
a parser can't do that
why the changes to link_entity?
actually nvm, that's much nicer :)
brianfreud wonders how hard it would be to add an optional date field and optional generic string field to URL AR handling
warp
aCiD2: type.search doesn't match subtypes of URL::
of course, I don't see any other way yet - but this is a bit ickier than I first imagined it to be
I don't think linktype_to_model belongs in Data::Utils
that belongs in Data::Relationship probably
warp
ah, right.
aCiD2
Actually
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
god damnit, someone give me a java job
warp
I like factories.
aCiD2
:)
warp
they make things.
aCiD2
can you make it an enterprise abstract factory factory factory?
warp
aCiD2: the good thing about a factory would be that the linktype doesn't need to be passed around
aCiD2
si
plus it works in the case when you don't even have a link type (like url/<gid>)
warp
aCiD2: but having a big switch statement dropping through dozens of regexes to find the correct entity sounds pretty bad too.
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
warp
(or they register themselves and the factory tries them all)
aCiD2
the url factory can then cache that in a Map[RegexRef, ClassName]
luks
it's one, exactly one regex :)
not a few dozens
I wouldn't spend two days on something like this
warp
luks: now. yes. but I expect we'll add amazon, imdb, and many more in the future.
luks: true.
luks
only I have nothing else to do
which I guess isn't the case
you wanted to go agile? YAGNI
aCiD2
yagni doesn't mean use a bad design
a url should not depend on a link type to have a pretty name
luks
I totally support good design
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
luks
but if I have lots of more important things to do
a single if will not kill me
warp
aCiD2: anyway, do you have time / interest in taking this over? I'd rather not spend more time on this ticket.
aCiD2
sure
warp
yay. I'll assign the ticket to you then. thanks!
aCiD2
push that branch out and reassign the ticket to me with a comment when you get a chance
warp
will do.
aCiD2 goes back to wondering why this migrated edit type think the release is in a completely different release group
brianfreud
it's lonely
aCiD2
if it's lonely it should go to mozart, not some random NAT release group
:P
navap
haha
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?
luks
yes
row_id goes to edit_release
it's used for looking up edits
maybe there were bugs and the row_ids will not resolve
some of them
warp
lol
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
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)
luks
is the release group totally wrong or something possibly related?
I think it's because the correct release group was merged later
aCiD2 keeps poking
luks
which is why I asked if they can be related
check the result of the subselect first
aCiD2
that's empty, so I just use <old_id> (that was pseudo sql)
luks
I think tmp_release_merge are actually release event IDs
aCiD2
ah..
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
luks
my memory is really bad
I don't remember how does the upgrade process work
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
