#musicbrainz-devel

yay.

(to github)

warp: we'll get there soon.

in manageable chunks

not a huge hard-to-review blob :)

I want Batsy to get more core functionality going in order for her to pass the mid-term.

after that we'll get a review out.

ok

warp: there isn't that much code yet.

I need to go over the rest of it and get the other widgets up to speed

Batsy: ok, sounds good.

hi djce.

moin

do you have anything for our review?

speaking of huge hard-to-review blobs on codereview, mine is still sitting there; I haven't really done much in the last week

No progress other than opening a ticket or two, closing a ticket or two (that were solved long ago).

djce: ok.

ianmcorvidae: lets see if we can get that worked down this week.

tinkerd with some more statistics but that's about all; probably will push something in that vein later this week, and then evaluate where I'm going next with the timeline graph

been on hols but back now, and as/when I get free time, mediawiki remains my focus.

but the schema change release takes priority atm.

of course, I figured that was why it hadn't been gotten to (also since it's a giant blob, sorry about that)

ianmcorvidae: It's more the giant blob problem

but I have been trying to get it reviewed

bitmap: prod

ianmcorvidae: when will we be able to visualize other stats than the core ones?

ruaok:u are taliking about a db schema change, but what is the change ?

hi

Batsy: also please post a new blog post

murdos: once I add them; that's the other thing on my list for this week

bitmap: how is your gsoc project coming along?

shouldn't be hard, I just need to assign colors to them and some boilerplate

I posted a short one this morning, just a quick update

ijabz: they are not really changes to the schema as much as they are structural.

we're combining the raw and readonly DB to live in one DB.

murdos: if you have priorities re: what you'd like to see added soonest, it'd be great if you'd PM me so I can focus there :)

right

I'm pretty happy with last week, since I got a good patch out to fix issues with Picard's request handling (http://codereview.musicbrainz.org/r/1386/), and my collection-management work will probably be pushed out and have a review published today

ijabz: that reminds me, we need to change how cartman builds indexes after the release.

then I'll be working on bug fixes for that for a few days, but it seems pretty stable

? speak after meting

ijabz: ok

it'll be nice to have people test the collections stuff too, once I push it out. :)

ok, anyone else for review stuff?

I could in the context of the md chnage

ijabz: ok, thats up later.

lets move on to linkedbrainz.

BarryN: go!

ok, so we didn't make much fuss at the NGS roll-out but, thanks mainly to kurtjx there's a lot of RDFa on MB.org

see, for instance, all the red boxes (each an annotation) at http://linkedbrainz.c4dmpresents.org/content/li...

our next plan was to get an endpoint for queries in SPARQL, the RDF query language against the live DB

this didn't work very well, terrible scaling

:-)

so we worked on automating the RDF dump from the live DB

and loading this into a graph DB (where things are indexed at that level)

can u say what graph DB?

this went well enough that I could ship a DB instance (OWLIM, for the record) to phaase = Peter Haase at fluidOps in Germany

ah ok

he put this under the Information Workbench for a demo today, see e.g.: http://iwb.fluidops.com:7883/resource/?uri=http...

as you can probably tell from the page load the speed here is much better

each widget on the page is backed by a SPARQL query

see http://iwb.fluidops.com:7883/resource/purl-mo:M... (and click edit to see the mark-up)

interesting.

so (which outstanding tasks haven't moved forwards while we prepare this), the LinkedBrainz tasks are to:

1) start dealing with the tickets relating to the RDFa

I'm really glad that we don;t have to host the sparql endpoint. :)

2) to put the RDF dump production live

3) to talk with Peter about the licensing implications of advertising this endpoint (and its lovely widgets)...

on the latter from the Ontotext (producers of OWLIM) point of view, we've agreed a non.commercial use license subject to having a 'powered by OWLIM' badge

regarding 1, can someone create an account so they can be assigned to someone other than kurtjx? :P

(on jira)

so it seems the funders are happy (to be confirmed tomorrow), but I'd welcome feedback from the MB community

nikki: I already ask BarryN to do that...

yes, I'm sorry that I haven't yet

(review prep)

just to repeat it here: we are happy to host the endpoint and RDF-based portal for LinkedBrainz, there is potential to do a lot more based on our platform.

BarryN: I'm happy so far. but we should talk about what to do if someone wishes to use it comercially.

indeed

phaase: thanks!

the dump, of course, would be generic so potential to load into any RDF DB

i've got tickets! oh my

disclaimer: I'm going to work for Ontotext from next month

BarryN and I are going to speak more after our release, so then we can address more of these questions.

that's me on status, I think

ok, thanks!

and congrats on the new gig.

ok, cover art archive is next!

twoot

so, the board of directors has approved the project in its wides scope.

meaning that we can host anything we want to host at the archive.

unfortunately I do not see a method by which we can avoid having the images flow through musicbrainz servers.

at some point someone needs to provide the keys for the IA S3 service.

what do you mean by "flow"?

so we need to have *something* running on a IA machine.

ocharles: meaning that when someone uploads an image, it should not flow via a musicbrainz machine.

right, well why does it have to?

you mean the image data must never hit an MB server?

djce: correct. for legal reasons.

were we going to allow uploads through MB into the CA archives?

ocharles: someone, not MB needs to write to their S3 like service.

ruaok: well, the images themselves can be uploaded directly to S3 with a simple form.

ok. What about the requirement (as stated in the topic, the other day) to "not run any service on the archive host" (iirc)

and that someone needs to have the private/public key to write to the IA S3.

ruaok: that form however will have to be served by some perl/whatever code which can generate the temporary amazon keys

djce: that is the goal and if we can get away with that, it would be awesome.

Why is that the goal? What's the purpose?

ruaok: why is it a problem?

djce: the goal is allow a MB release id indexed cover art repository that is curated by MB, but none of the images ever touch MB.

the hosting and uploading needs to all be handled by archive.org

warp: not sure that IA can give us temporary keys.

we may be able to only get permanent keys.

the problem is that we can't really consume any IA engineering resources.

I assume the keys would allow full read-write access?

just their bandwidth. :)

djce: yes, for those who have access.

and we obviously dont want to expose the keys to everyone.

indeed.

but, that isn't the goal of this update.

I just wanted to put the thought out there and give an update.

Thus, a simple app is required which knows the keys, and (e.g.) only allows "add" operations

i.e. not overwrite, not delete

if anyone would like to disucss this after the meeting, then lets do that.

djce: exactly!

but if we can avoid having to host something at IA that would be best.

not unlike https://github.com/djce/blob-server actually :-D

next tuesday I'm going to google for my annual begging visit.

I'll spend the afternoon at the archive talking this process through.

ok, onward now.

ijabz: mmd changes!

ruaok: one on of us should probably look into what _exactly_ is needed for e.g. s3 upload forms.

The changes themselves are not such a major issue, but the issue is workflow

warp: read this: http://www.archive.org/help/abouts3.txt

MMD is a public api, as such the MMD should always be revewed and chnaged before accompanying code chnages

ijabz: yep, that is why ocharles posted in mb-devel

That was too late

ruaok: oh, so it's not really s3 then? but an archive.org API which behaves similarly?

yea, that was my bad there

warp: yep.

He had already changed code and released it so the code being served didnt match the MD

ruaok: right, that wasn't clear to me, thanks.

warp: np

ijabz: oh. I didn't realize that.

I made the changes, ran them past one person, then just shipped, which isn't good