Re: Call for maintainers - Musicbrainz RDFa markup

Hello,

On 09/06/2013 09:33 PM, Barry Norton wrote:
> Ah, apologies, I hadn't spotted that there was an update to the VM in
> August, I was already preparing for the Summer School here.
>
> While I agree that having separate RDF resources might be the best
> solution, I'm not convinced that it would be so easy to make the current
> JSON API into JSON-LD, and the important thing would be to have
> redirects when content-negotiating from the existing (non-decorated)
> document URIs - is that (now) possible?

MusicBrainz uses nginx as a load balancer and fcgi server in front of 
the perl codebase.  nginx doesn't do content negotation, so that would 
probably have to be implemented in perl.  The perl code could either 
directly proxy to a backend service which provides the RDF 
representation or return the appropriate 30x redirect response.

 > If it is, wouldn't it be easier to directly return the RDF in 
response to an
> "Accept:application/rdf+xml" request rather than 30x-ing it?

I personally prefer decorated URLs because they're easier to 
play/prototype/experiment with on the commandline and in the browser.

> There are also a bunch of manipulations in the R2RML mappings that go
> beyond adding context - i.e. manipulation of Wikipedia URIs into DBpedia
> ones. That said, things are closer between the RDF and API structure now
> that there's the event/geo information in first class release events.
>
> Is another solution to serve pure RDF resource representations from
> R2RML mappings directly over the database? Or at least a replication of
> it? It would be nice to have that hand-in-hand with RDF dumps.

I haven't tried running the R2RML mappings myself, if that can be used 
to provide an RDF webservice that does seem like a good solution, 
especially considering most of that exists already :)

-- kuno / warp.

Received on Friday, 6 September 2013 20:14:10 UTC