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.
MetaBrainz Blog 
Hello!
Can you hold off for now? I’ll send this blog post around and try to find someone to maintain it. A couple of (possibly biased) reasons why I feel the RDFa should stay in Musicbrainz:
* Sometime it’s much easier to use Musicbrainz’s RDFa than its API – you see a bit of data you need on a page, no need to find the corresponding API call, you just parse that page and extract the bit of data you need. Very long term I think this is a sensible way forward – the website as its own API.
* Schema.org, OGP, etc. compatibility – for example it’s likely that if we mention it on the public-vocabs W3C mailing list, the RDFa in Musicbrainz could be used to enrich search results around Musicbrainz pages.
Anyway, I’ll share this blog post with a few mailing lists and get back to you 🙂
Cheers,
Yves
Hello!
Can you hold off for a bit? I’ll circulate this blog post with a few mailing lists to try and find a maintainer. A couple of (possibly biased) reasons why I think the RDFa should stay on Musicbrainz:
* Sometimes the RDFa is a much easier way to get to Musicbrainz data than the API. You see a bit of data you need on a Musicbrainz page and you can just extract that bit of information from the page itself, rather than having to construct the corresponding API call. Very long term I think this is a sensible way forward – the web site as its own API.
* Compatibility with schema.org, OGP, etc. For example I think mentioning the Musicbrainz RDFa on the public-vocabs W3C mailing list could lead to enriched search results for Musicbrainz pages.
Cheers,
Yves
Hi,
I do care about this – for the same reasons than Yves – and I’m happy to support the code as well.
Alex.
Which technical skills are required (besides RDF(a) knowledge)?
Its mostly just editing our templates, possibly with a bit of perl thrown in. But, we’re wondering if a separate end point ( /artist/8f6bd1e4-fbe1-4f50-aa9b-94c450ec0f11 vs /artist/8f6bd1e4-fbe1-4f50-aa9b-94c450ec0f11.rdf ) would make sense instead of embedding the RDFa directly into our pages, which makes maintenance harder and more brittle.
Hello,
I also care about this, partly for the reasons mentioned above, partly because we at QMUL have several research projects that aim to use the service and integrate it with other Semantic Web resources. We also have an application under trial with a view of commercial use in the near future.
I’m happy to contribute to maintaining the schema and I have RDFa knowledge, though I’m not a Perl user, so I probably won’t contribute to maintaining code directly.
Cheers,
George
Hello,
I’m not a Perl user, but I have RDFa and microdata knowledge. I would be happy to contribute also. If you want to check my work, you can take a look at http://getschema.org .
Regards,
Cosmin