#musicbrainz-devel

ianmcorvidae: Did you look at the Cornel West stuff?

any reason we chose a subdomain for changed MBIDs over a path component?

cd

bah

no such file or directory: bah

ocharles: Geek!

:D

Is there a way to do git format-patch for the initial commit of a repository?

Freso: git show HEAD?

ocharles: That doesn't look like something git am will parse... ?

http://stackoverflow.com/questions/11197812/how... then

ocharles: Ah, cheers! I ended up just setting --date and --author manually in the commit, as my own searching did not give me that SO page. :|

ocharles: subdomain? I do not understand the question.

warp: it was more at ian

why we have http://changed-mbids.mb.org/ over http://mb.org/ws/changed-mbids

hah, that looks way too specific for a subdomain, I agree.

I'm sure I'll be told I'm being awkward if I mention that

change-ids doesn't look like a web service though

I'd argue with the current form it should be on data.mb.org

yea, but i think it should be more of a service

that .gz should go away in favour of HTTP headers, and the index page should be machine readable

I wonder what's the target use case for this

Being able to fetch a list of all MBIDs that have changed since $x

So headphones doesn't have to poll for changes for the entire media library

(Amongst others)

so you keep downloading these files, and if an "interesting" MBID appears in them, you update your MB data?

I think that's the idea, yea

or more - you download all files since $x, aggregate all the MBIDs you're interested in, then fetch them

with 10-20 kb per hour, I think there is going to be a lot of catching up if you are one week behind

10-20kb per hour with duplication

the set of mbids you're interested in probably doesn't grow linearly with file size

(ie, if an artist is repeatedly updated, they will appear in every packet, but you only do one request)

but you have download all mbids, no?

you have one file per replication packet (I assume those numbers are replication packets)

yea, you do have to download all of them

alastairp: re: dynamic work attributes, I'd like jasrac work id

which would be a text field, I guess.

(several of us have been entering them in annotations - https://beta.musicbrainz.org/search?query=type%...)

nikki: cool

I'll need to see if we can fit text into the schema. I think the original one expects fixed lists

Well, it's the same free text field as catalogue numbers for classical

So just list them together :)

:p

are we currently dealing with translations in things like work types, or instruments?

I think the answer is no, right?

yes

well, "they're translatable"

but currently stored as rows in the database?

yes

ok

we extract a whole bunch of things from the db, in fact.

ah, right

hmm

http://users.musicbrainz.org/~luks/tmp/works.png so from this, each work type has a different set of attributes

which works for some things

but not for, say, catalog numbers - since they might apply equally to all

am I reading that right? (luks)

work types in that images meant something different than they mean now

ok

they were more or less describing layers

e.g. symphony vs movement, etc.

heh

Yeah, what work types *should* mean :)

hmm, right

(with our current concept moving to tags)

so current 'types' kind of become attributes?

(well, a tag-like system, not the current tags)

alastairp: the current types are pretty much genre tags

Unsure what the best way of dealing with them would be. Probably the same we do with genres, once we do something with them

Someone did propose renaming that to "work form" for now and adding "work type" with the meaning luks said

(CallerNo6 maybe?)

yes

That would seem reasonable to me - only problem I might see is the ws renaming

Although I honestly doubt anyone's using work types anyway so I don't think it'd break anything

are any of our existing types actually types?

"song" maybe is a type

but then people will argue that instrumental songs are not songs, so I'm not sure :)

It's certainly a form - you *might* see it as a type too, but...

I'd just call songs "full works" or something :p

(have 3 levels, "collection", "work" "part" or something)

I bet that'd get people arguing whether song cycles are collections of works, or works of works :)

I think we should have different hierarchies for different music styles

"full work" doesn't mean much in "popular" music

Well

What hierarchy *does* make sense in popular music?

and things like jazz have they own classification

Isn't it pretty much flat?

it's just one entry :)

I mean, the only use of "part" and "collection" as types is to allow people who want to see just full works to hide them really

Unless I'm missing a very clear use )

*:)

(certainly, parts can have its own key different from the full work one, its own cat# in cases...)

(collections certainly get opus numbers)

well, I've learned something about dancehall this weekend, so for example I'd like to see it to be able to track "riddims" :)

or jazz standards

which are not really full works, but they are not parts either

heh riddims

hmm, jazz standards are interesting

Isn't that better served by a specific relationship between the riddim and the derivated works than a work type?

what I mean is that different music styles structure music differently

(I know nothing about jazz)

especially because the definition is so loose anywa

and I'd like to track these semantic components

(well, that it bores me)

I'd like to be able to mark hip hop beats somehow separated from the full works to for when they get reused

But doesn't that affect small enough bits of the DB that it'd be weird having it as "types" anyway? the thing about part and collection is that they're general

Dunno :/

so, when someone reuses part of an existing recording?

I don't think it would be that weird

they beats can have certain artibutes that have no sense for things like classical movements

so I think it makes sense to be a little specific here

Hmm

I guess I would see that work *if* you selected a type in the same place you then chose the attributes

(which I'd expect not to be the general edit work interface - that should stay as simple as possible)

well, I assumed it would work that way

I assuming it'd be some sort of dropdown for selecting an attribute that would add a new row

err

I assumed

so, am I getting from this that we need some further discussion planning to rework this stuff, or can we do attributes on top of current works and add this later?

alastairp: both probably? :)

luks: hmm, what attributes do you see for beats btw?

BPM came to my mind, but it's probably a bigger issue the other way around

you don't want catalog numbers on beats

Why? :)