#musicbrainz-devel

warp, are you busy?

somewhat

actually, I think I can use test.mb for this, sorry! :)

np :)

warp: what dataset are you generating the ws.sql from? The latest NGS dump or a more recent mb dump?

ngs/20100616

Hm.

I'm doing a reimport now but because I need moderation_closed mine is going to be more up to date

Guess I'll have to fix some tests

aCiD2: oh, I noticed there are a few /ws/2 patches from me still on code review

aCiD2: can you review those and merge those in soonish, they'll be much harder to merge later on if you're working on /ws stuff.

(or I can merge them if you give them ship its)

Ok, will do

some have shipits

really? I thought I checked this morning.

they have for a while :) They are at the bottom of the list of reviews

hello, perl noob question

the .tt files are using the template toolkit, correct?

yeah

great

better than no progress :)

:)

thinking about just constructing rdf/xml in templates and avoiding librdf-perl

and probably just use librdf-perl for test

can anybody point to where in the code the uri routing stuff happens?

kurtjx: You're looking to turn /artist/<mbid> into something with content negotiation right?

yeah - well at this point just trying to understand the request cycle a bit

is that buried in catalyst?

Catalyst manages it for you, yea

Controller::Foo with a sub "bar" will generally match /foo/bar

but there's more to that with :Chained actions

ok

The easiest for now is to probably have a separate view (MusicBrainz::Server::View::RDF) and choose that in MusicBrainz::Server::Controller::Root::end if the user looks like they are requesting RDF

but that means you're limited to the data available in the HTML pages, I'm not sure if that is or isn't a problem

that should be ok

well if there's some pagination we'd want all pages to be in one RDF doc

grep -r Controller:: ./

ah there they are :-)

really?

really? I don't think you'll ever get that granted - we specifically added pagination because having no pagination just kills our db servers

i see

so, for example, listing all of an artist's release in one go is just too hard on the db servers

It might be doable now that we've restructured queries

but we just need to say how NGS holds up first

k

the problem is mainly things like bach and mozart, isn't it?

yeah, or James Brown

the really prolific

i'll see if i can find a way to make linked data compatible with pagination

if that's the james brown I'm looking at, it's nowhere near as much of a problem :P

244 releases for that one, 2462 for bach

well yes you're right - Bach is an order of magnitude worse - i'm just more of a James Brown fan ;-)

:)

i think we can work with pagnination

s/pagnination/pagination

see i know perl

k i'm off for a bit - baby dr. appointment...

cool website! I didn't know there was such a community behind rdf

cya kurtjx

you didn't!?

i really didn't maybe because we killed our rdf service, and I just assumed that because rdf was dead

ah, but we killed our rdf service 'cause it sucked and nobody liked it :P (or something)

which I wrongfully assumed was just a downfall in rdf, not us just sucking :P

I hated rdf and thought it made absolutely no sense and wondered why anyone would use it, until simon showed me the n3 or turtle or whatever way of writing it and was like "whoa. that's so simple! it makes so much sense now!"

I suppose I'm spoilt 'cause I live with someone who's like "rdf! semantic web! yaaay!" :P

haha

yeah, rdf/xml makes rdf a terrifying thing

it made sense to *me* but I may be a little bit nuts :P

(also it wasn't my first introduction -- semantic mediawiki was, which is very limited but not a bad introduction)

I think the n3/turtle/whatever way really clicked with me because it was just like some of the stuff we did in semantics

whereas the xml stuff was like all containers and boxes and really verbose

heh yeah

aCiD2: http://en.wikipedia.org/wiki/Notation3

already there

ah

ah, so it's just a more concise serialization format

yeah rdf/xml sucks, rdf/n3 ftw

more readable, at least

it reads almost like sentences

k now i'm off for real

yeah, exactly

warp: what do i need to do I need to do to your dump script to get it to export label/label relationships?

meh, I think you're gonna need to do it :( Mine is just generating FK violations

aCiD2: Instead of showing the mirror server error page for user pages, how about showing a 404 instead?

I think the mirror server page makes sense for things like logging in and registering, but since a slave shouldn't have user data we could just return a 404 for anything in /user

hrm

And non-user pages like /verify-email would still show the mirror server page

what status code are we using for that?

forbidden?

Currently nothing.

It should probably not be 200

Yeah I missed that

I'm happy using 403 for those pages and 404 for user pages, I think that makes sense

So are you saying use the same mirror server page and return a 404?

Or the proper 404 page.

(I prefer the latter)

I think a page that says "this data might be available, but as you are using a mirror server it is not available"

with a 404

Okay

FYI: http://blog.musicbrainz.org/?p=624

kurtjx: what will happen for the release formats MO doesn't have? will you try and get them to add them?

nikki: we'll just send Kuno the enforcer after them. :)

and make sure they add them.

nikki, i _think_ the solution is that each release format is an instance of mo:Medium and be somehow bind a mo:Medium to a release (mo:Release)

question - how does the webservice handle queries about artists like Bach who have thousands of works ?

is there pagination there?

kurtjx: yes, in the browse mode there is pagination.

in our world we call this the "JSB Problem" :-)

kurtjx: http://wiki.musicbrainz.org/User:kuno/ws/2

thnx ruaok - so you would agree that the RDF must have some pagination as well?

yes.

the whole issue of WS granularity is pretty damn important.

sounds good, i could use a beer

so, in creating now a third version of our web service, we've learned that keeping the data returned from one request as small as possible is best.

that means the cost per request is lower, but that more requests need to be made.