Pagination in RDF

  • user warning: Unknown column 'captcha_type' in 'field list' query: SELECT module, captcha_type FROM captcha_points WHERE form_id = 'comment_form' in /var/www/drupal/sites/all/modules/captcha/captcha.inc on line 64.
  • user warning: Unknown column 'captcha_type' in 'field list' query: SELECT module, captcha_type FROM captcha_points WHERE form_id = 'user_login_block' in /var/www/drupal/sites/all/modules/captcha/captcha.inc on line 64.

The HTML pages on MusicBrainz use lots of pagination. This not only prevents the end user from being overwhelmed by a listing of thousands of tracks, it reduces the size of HTML pages to something manageable and also ensures a smaller and predictable load on the database server.

In RDF, it would be preferable to avoid pagination. However, this is not particularly practical for artists that are associated with many, many releases and recordings. The problem becomes acute for classical composers like Bach who are credited with tens of thousands recordings. Arguably a more appropriate utilization of NGS would have composers such as Bach credited to works rather than recordings. However, the general opinion of MB editors seems to favor crediting composers as well as performers on recordings. Therefore, the complete RDF resource description for Bach would be immense. This would cause an unacceptable load on the database server and long wait times for dereferenced URIs. One solution is to use pagination in RDF. Terms to support this exist in the XHTML Vocabulary which is generally intended for use with RDFa on paginated websites.

A rather lengthy discussion about this topic ensued on the Music Ontology specification mailing list. The idea of using RDF Views technology was brought up, however this does not seem to address the Bach problem directly. However, this approach has many advantages and should not be discounted quite yet. Perhaps the simplest approach would be to exactly mirror the pagination of the HTML in RDF or RDFa, although from a modeling perspective this is not optimal. A wiki page for collecting and discussing implementation options has been created.

Hi Kurt Sounds like an

Hi Kurt

Sounds like an interesting 'scalability' issue here for linked data, if that's how you'd characterise it? Does there appear to be a best solution or workaround here that's coming out of your discussions? Is it a problem that's specific to linkedbrainz, or is it the sort of thing that applies quite generally to other projects outputting linked data would you say?

Cheers,
Adrian (JiscEXPO programme synthesiser)

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options