Re: Call for maintainers - Musicbrainz RDFa markup

Hello!

Sorry I'm rather late to the party here.  I wrote the first RDFa
MusicBrainz implementation.  I am the originator of this technical debt :)

When I worked on the project, and I think this is still true, MB used a
perl-based model-view-control type framework for it's site.  From my view,
RDFa was a bit incongruent with this type of framework.  The RDF(a) is a
translation of the model layer that needs to inject things all through the
view layer.  The solution we came up with at the time was to just dump
loads of template functions and translation logic into a central location
and pepper calls to these functions throughout the templates at appropriate
places.  I'm sure loads of MB devs hate me for it now.

I guess I just wanted to bring up this issue.  I think it's rather unclear
to me still how RDFa should fit into an MVC app.  And given the ubiquity of
this type of web app, I think that's a real problem for RDFa.

Are there good examples of how to handle this?

Also, if you need somebody to curse at for the MB RDFa implementation, I'm
here :)

-Kurt J




On Mon, Sep 9, 2013 at 6:59 AM, Yves Raimond <yves.raimond@gmail.com> wrote:

> 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.
>
> --
> 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.
>