Tag: RDF

LinkedBrainz: Alive and well!

Barry Norton has been a star and has created and hosted RDF dumps of the MusicBrainz data and also established a permanent SPARQL endpoint for our data on linkedbrainz.org.

The timing of this is perfect, because our next release will remove the RDFa from our pages. Proper RDF data and a SPARQL end-point are the best ways to move forward with MusicBrainz data in the context of linked open data.

This gives the MusicBrainz development team the freedom to focus on making MusicBrainz better while leaving the nitty gritty parts of making our data friendly to the linked open data hackers to experts like Barry.

Thanks so much for making this happen, Barry!

Our embedded RDFa will be going away in two weeks

We’ve been trying to find anyone making use of the RDFa embedded in our pages, but we’ve been unable to find anyone.

Given that the RDFa makes our templates much harder and cumbersome to edit, we’ve decided to go ahead and remove our RDFa support in two weeks time.

Since we could not find anyone who actually uses our RDFa, this shouldn’t be a problem. But we suspect that someone, somewhere will be angry with us for removing the RDFa support without any warning or without being asked for feedback. :-/

Our RDFa dilemma

A few years ago Queen Mary University was awarded a grant to implement modern RDF support in MusicBrainz. The RDFa portion was implemented on our server and has been in our pages for quite some time.

However, the code to implement RDFa is brittle and has not been maintained through a number of schema changes and is quite broken at this point in time. When wondering if we should fix this or remove it, we could find no one or no application that we know of, that makes use of the embedded RDFa in our pages. And no one stepped up to fix it and the author of this code is not responding to emails inquiring about this.

At this point, we’re ready to remove the broken code from our pages in an effort to remove technical debt that has accumulated over the past few years. If you care about RDFa support in our pages, please speak up now. Ideally anyone speaking up would also volunteer to adopt the RDFa code and see it through life as our schema changes.

Queen Mary University receives grant to implement new RDF web service for MusicBrainz

The School of Electronic Engineering and Computer Science at Queen Mary University in London just received a grant to implement a new RDF based web service and a SPARQL endpoint for this web service.

The grant will be administered by Queen Mary University and will mean that one developer will be paid for one year to work on this project. This developer will be part of the MusicBrainz development team and will take part in our usual activities, meetings and code review process.

While we have an RDF based web service already, its worth noting that this has been stale for many years and has not been developed in favor of our XML web service. The XML web service has seen an amazing adoption and it would seem that having another web service would be superfluous. They key here is that the Linked Data world (formerly the semantic web) predominantly uses RDF as its preferred means of linking data. In order for MusicBrainz to continue to be well linked to the Linked Data world, it is important for us to continue to support an RDF web service. This grant very cleanly supports this goal and it also shows that the academic world thinks that MusicBrainz is of value and that it should be supported.

Congratulations to the Queen Mary University team that worked on this application! For nearly all of the gory details (the detailed budget figures have been stripped from the application for privacy sake) please see the PDF grant application.

I will be working with the hired developer to write up a detailed wiki page that will explain this project in much more detail. In the meantime if you have any questions, please read the grant application.

Congratulations to the whole team at Queen Mary University London!

Web service users: What do you think of our current URL structure?

I’m about to finish writing the web service (version 1 & 2) for NGS, based on the work that Lukas started a few months ago. The NGS web service currently does not have a compete means of tweaking how much XML is returned for a given resource. Lukas wondered if we should keep our existing approach or start using a new approach that Last.fm (and others) use.

Compare our current approach:

/ws/1/release-group/052c7adb-5e2d-3cf3-b303-6c2a7d3e5b1c/?type=xml&inc=releases (docs)

to the Last.fm approach:

/2.0/?method=album.getinfo&artist=Cher&album=Believe (docs)

Should we keep our current resource focused URL structure or move to a method centric approach in our v2?

If you’re a fan of the old skool structure, please leave a comment and tell us what could be improved. What do you like about the web service? What do you hate?

For some background — as of the NGS release we will be making a lot of changes:

  • the old RDF web service will no longer work.
  • The old v1 XML interface will continue to work, but not optimally since we will be shoe-horning the spiffy new NGS XML into the old skool v1 XML. Concepts like artist-credits and works will not be available in the v1 compatibility interface.
  • The new v2 XML interface will expose all the NGS goodies like artist-credits and works.

Getting ready for our Next Generation Schema!

After many years of planning, anticipating and gathering resources, we’re finally tangibly close to our Next Generation Schema (NGS).

This blog post is intended as an official notification to everyone in our community and our customers who are using MusicBrainz services right now. Our next generation schema is drastic evolution for MusicBrainz — we’ve included many of the features that our customers and our community has asked for over the past few years. This means that if you’re using the MusicBrainz data right now, you will need to prepare your systems in order to be ready for the switchover when it comes in the fall. Please do not delay examining our new schema — this change is drastic change from our previous schema!

Our current plans are to enter beta testing of the new server on August 31. The exact release date is very much dependent on the results of our beta phase, but I hope to have the release within 60 days of entering beta.

The most important changes that you will need to consider/address:

  • No old (RDF) web service — the old RDF web service will no longer be supported as of NGS.
  • We will provide an XML v1 web service that is backward compatible to our current XML web service.
  • We will also provide an XML v2 web service that will expose new NGS concepts.
  • Postgres 8.3 will be required. Upgrading your old database will not be possible. You will be required to import the first post NGS data-dump in order to upgrade to NGS. Our provided upgrade script (see below) is very useful for testing purposes but not suited for upgrading deployed servers.
  • MBID changes — The MBIDs will be stable and maintained for artists, release-groups and tracks. All of the MBIDs for our current releases will also be kept, but we are changing what we are calling releases. Essentially all release events (with label, date, country and barcode information) will become releases each with their own MBID. This means that we’re adding a whole slew of new MBIDs for the releases that will not be assigned a legacy MBID.

NGS is documented on our wiki — please take some time to read up on our documentation! If you’d like to play with NGS now, follow these steps:

1. Download and install the 20090524 release according to these instructions. For going to NGS, installing a database only install is the perfect approach. Download and import an existing data set.

2. Download the NGS codebase with subversion.

3. Follow the install instructions. Instructions are included for how to migrate the 20090524 data to NGS — please note that the upgrade script may run for quite some time!

There are a lot of changes to the database from the current release! Please note that we’re done with the overall database design — I am not anticipating major changes past this point. However, I do anticipate a few smaller changes as we get closer to our goal. We will keep the schema diagram and documentation up to date with our changes.

If you care to follow our progress getting to NGS, please see our roadmap.

RDF Web Service will cease to exist after the NGS release

The old skool RDF based web service (at /cgi-bin/mq_2_1.pl /cgi-bin/mq.pl /cgi-bin/rdf_2_1.pl and /cgi-bin/rdf.pl) will cease to exist when we release the Next Generation Schema (NGS) release that will go into a beta release on August 31. This web service has been deprecated for three years now, its finally time to put it out if its own misery.

As of this release the Classic Tagger will completely stop functioning. RIP Classic Tagger!

The old RDF based web service has been deprecated

The subject pretty much says it all — the new XML Web Service has been debugged and is now stable. This new web service was designed to replace the old web service since its better designed, more concise and a lot simpler to use.

If you are using the old web service directly or have been using libmusicbrainz (1.x/2.x) or libtunepimp (all versions) then you are using the old web service and you should make an effort to migrate your application to use the new XML web service. The old web service will stay in service for all of 2007, but we may get rid of it as early as 2008.

Technorati Tags: ,