#musicbrainz

sults: i'm a dumbass, your pasted version works great

thanks!

Are you considering adding location entities first, and later turn them into actual locations with mapping and more info?

Wizzcat: also, the event_artist table makes it look like you designed it for concert listings, but I thought that was something still quite disputed about whether it belongs in mb at all

(ticket, whatever)

nikki: is it?

nikki: I have no idea, is it?

Why would it be?

Seems obvious

seems like a mmajor asset to mbz

I don't remember, maybe ruaok knows

I mean, *past* events at least are factual data

concert listings in musicbrainz

what else would events be anyway?

(until they stop being future)

SultS: i mean the one from pastebin

Or keep them "pending" until somebody confirms it actually took place

it works perfectly, thanks

I would love to see future and past concert listings.

(after the date)

i am actually for this

and maybe even "current" concert listings.

imagine, relating http://musicbrainz.org/search?query=woodstock&a... to the actual place

would be cool

ruaok: wasn't it disputed whether we should include it, or am I imagining things?

which "it" ?

concerts in general?

concert listings in mb

or http://musicbrainz.org/search?query=artist%3Abe... to "abby studios"

etc

nikki: yeah, but the concensus was to try some small stuff and then see what happens.

how would we try small stuff?

either we have it or we don't :/

just saying which artists are on tour.

not doing fancy things like geolocation.

i think thaat's a lot more obscure

since "on tour" stops happenign whenver

but "had concert at" is documentable as "has happened" not in "is currently happenign, whilew i'm typing this atleast)

the wa "on tour" means

ruaok: hm, but this suggestion is for mb to collect/store concert listings itself, not for using third party data

ah, no.

"no"?

we should not do that. there are a lot of companies putting a lot of effort towards collecting that data.

I think this is best to partner than to do it oursevles.

so I'm not imagining things. that's good at least

Partners don't give a shit about past data

Past data is the one that's useful to us

So, I see a clash there

reosarevok: songkick does.

they even have a wiki with setlists.

brb just sat on a bag of furniture glue

lol

that would make a great tweet. :)

clearly taking advice about sticking around too literally.

lol

Back

setlists are clearly future, but considering that we need location anyway, it's a fairly short step to add simple concert listings

setlists are historic.

they'll make bootleg work waaay easier

I don't see what makes it less useful data from an archiving point of view

Also, that, yeah

Linking live recordings to their actual events

(less useful than the recordings)

sure they're useful, but it's a pretty big addition

Wizzcat: meant concerts in general, not setlists specifically

oh sorry, misread, then we agree

Now, if we get a partner who is willing to let us import their whole backlog of events, give us replication, and allow us to edit the results, that's good, but I still think we should have the support and just import that data

songkick has been really wanting to work with us.

so, if we want something, I can go ask.

but… we finally gotta do *something*.

yes, they do.

we've been dragging out feet trying to figure out what we want.

yes, they are.

so do we have any gsoc proposals for working on locations and events/

reosarevok: and yes, our summit was the CEO's birthday. I can understand that.

not particularly sexy I suppose, nor easy

tomato + ketchup FTW!

I'll believe their commitment when I see it, but I trust you for now. Now, how can we use their past data in a way our users can edit and we can serve from MB? I'm happy to let them keep the exclusive of future ones

:p

one one proposal so far: log stuff

(I'm not trying to be contrarian, I just think it's an important asset to MB and that it is pretty different from displaying future gigs)

reosarevok: I don't doubt them.

(which seems more like their thing indeed)

lets figure out what we want.

and if we can agree on what we want, I can go ask.

Does this setlist wiki of theirs provide them with any income?

reosarevok: its community managed. I think it is only indirect value to them

(as in, is it an extra service they give for fans or is it part of their core business in some way)

Ok

Do you have a link to an example? :)

i want to be able to link woodstock to woodstock, and http://musicbrainz.org/release-group/09ac3f31-d... to both the place(s) it was recorded and (it?) to a list of places they where on tour in this (casette has informatino about the "live after death tour")

and bootlegs to the place it was

but i, of course do not spec for everyone

speak either

heh

spec!

hit to key!

A very fitting typo, seeing that we're trying to determine the specs we want from our concert support

:)

Someone get me a link for these past-event setlists on songkick please

so imo anything that's supposed to fix mbs-799 should make it possible to specify those, and if concert listings work as a side effect or can be easily done in the future because we have locations, so be it. but the impression I got from the proposal was the opposite, that we'd be adding concert listings and later thinking about actually being able to do the things the ticket says

reosarevok: http://www.songkick.com/blog/2011/03/04/the-set...

Thanks

nikki: well the bug is for locations & events, what are events if not concerts

nikki: aren't both the same thing?

A location table

thought I agree they're two seperate thing, and need not both be implemented at the same time

reosarevok: there is nothing in Wizzcat's proposal right now that allows linking a recording to a location

Well, new relationships would need to be created, but that's not a schema change, is it?

it is if locations don't have relationships

Oh, I guess it needs a table l_location_recording?

huh? Why would locations have no relationships?

We're a relational database

That makes little sense

ask Wizzcat :P

nikki: I added that just now actually :)

I mean, how could you use it for concert listings with no relationships? :p

I don't know the db too well, so things go a bit slowly

Wizzcat: and l_release_location for when you don't know which tracks were recorded where? :P

Why not add one for each entity and later create rels when we think of them?

and l_artist_location for the things I suggested in the summary... l_location_url for adding urls... and yeah

I'll just write those down I guess

event_artist is basically just l_artist_event in disguise, events can have urls too, so l_event_url, and events can be part of bigger events, so presumably l_event_event... an event might be organised by a label, so l_label_event... :P

hey dawg, I heard you like events

So you will put events in our events so we can event while we event?

a good example of that would be a music festival with a series of different concerts at venues within the festival.

I certainly considered that, it's a fairly hairy issue which it doesn't make a lot of sense to specify before we actually have events

Sure, but it doesn't make a lot of sense to prevent it being added without another schema change by not adding an event-event table :)

i guess, wasn't really aware you needed a table for each relation

http://musicbrainz.org/admin/linktype are all the existing ones :)

luks_: You around?

nikki: well that makes sense I suppose, easy enough

also, I have a userscript that makes an annoying popup message whenever I go to a page for a recording with a linked video.

Ooh: http://boingboing.net/2012/03/27/soundtrack-rel...

heh, that sounds like the things I do

lol, available on digital download, vinyl lp, and audio cassette.