Re: Call for maintainers - Musicbrainz RDFa markup

Hello,

On Fri, Sep 6, 2013 at 9:16 PM, Kuno Woudt <kuno@frob.nl> wrote:
>
> Hello,
>
>
> On 09/05/2013 02:37 PM, Barry Norton wrote:
>>
>> By the way, the easiest way to work with the server is to use the VM but
>> this hadn't been updated since last year. I have an up-to-date version
>> for the Summer School and I'll bring it into the Museum next week.
>
>
> The current virtual machine image is from august this year, which is fairly
> recent.  For those interested, start here [1].
>
> [1] http://wiki.musicbrainz.org/Server_Setup
>
>
> And now that I'm responding anyway...
>
> As someone who has worked on the RDFa in MusicBrainz I do think that
> solution is untenable.  The current implementation is too brittle, and the
> website changes so frequently that making sure the RDFa is still correct
> after each change seems like a considerable effort.
>
> There are also a few things which I found difficult to express in RDFa, but
> perhaps that is just because I'm not that familiar with it.. for example:
>
>   On the release page where a tracklist is shown there is a single table
> which contains the entire tracklist of the release (even if it spans
> multiple discs).
>
>   At some point the discs were wrapped in a <div typeof="mo:Record"
> about="(tracklist/medium CURIE)">, which was invalid html so that <div> had
> to be removed.  And we want to keep these rows in a single table and in a
> single <tbody> so that their columns line up even when we don't specify
> widths for them, etc...

Ah that's odd - it should be valid HTML+RDFa - which profile are you
validating against?

>
> It is clash of trying to get the visual layout of the page correct AND the
> structure of the RDFa data embedded in it which makes working on this hard
> (at least it was for me :).
>

I agree - it's a major issue with RDFa, and we struggled with that a
few times on a couple of BBC projects. However I think it's worth the
effort - for example we use RDFa markup to unit test our templates
(given some data as an input, you should be able to parse the
generated HTML fragment and extract the same bit of data).

> So I think a better long-term solution would be to have a separate
> codebase/project which takes the current musicbrainz webservice output and
> turns that into rdf.  I imagine the easiest way to do that would be to take
> the existing JSON webservice, write a @context for it and some
> transformations of the data, and use existing RDF libraries to do JSON-LD to
> RDF/XML conversion.

My (very biased!) preference (as hinted in my comment to Rob's post)
is that the website itself is the canonical data source. Ultimately, a
JSON(-LD) API could even be automatically generated from RDFa markup
on HTML pages. What I like about this approach is that it forces the
data to be interlinked and discoverable, in the same way the current
website is. But it might not be practical in the short term though.

I'll send another email introducing the various people who told me
they were interested to you and Rob btw.

Best,
Yves

>
> We could make that available under urls like
> https://musicbrainz.org/artist/45a663b5-b1cb-4a91-bff6-2bef7bbfdd76.rdf .
>
> -- kuno / warp.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Music Ontology Specification Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to music-ontology-specification-group+unsubscribe@googlegroups.com.
> To post to this group, send email to
> music-ontology-specification-group@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/music-ontology-specification-group.
> For more options, visit https://groups.google.com/groups/opt_out.

Received on Monday, 9 September 2013 10:59:29 UTC