W3C home > Mailing lists > Public > public-lod@w3.org > September 2009

What about music-related URIs???

From: Kurt J <kurtjx@gmail.com>
Date: Sun, 6 Sep 2009 13:21:05 +0100
Message-ID: <b55af8eb0909060521w483451d4i1a3ebc29674b949a@mail.gmail.com>
To: music-ontology-specification-group@googlegroups.com, Linking Open Data <public-lod@w3.org>
Hello All,

It seems there are (too) many options for creating music-related URIs.
 They are mostly all based on Musicbrainz.org IDs (which is quite
appropriate), but it can be difficult to know which to choose.  I can
identify at least four different sources of artist URIs based on
musicbrainz ids:

1.  dbtune.org/musicbrainz
      pros:  there are uris for records, tracks, and artists (and
more), they dereference nicely; a nice comprehensive mapping
      cons: it's updated only periodically from the musicbrainz dumps

2.  bbc.co.uk/music
      pros:  well maintained by hard-working professionals; deref
nicely w/ fancy content neg
      cons: afaik, no URIs for releases, tracks - just artists; it is
arguably biased by bbc interests (not saying i believe this myself)

3.  zitgist.com
      pros:  samesAs links from DBpedia;  includes URIs for records /
tracks / etc
      cons:  not sure how often they are updated from musicbrainz;
not sure why, but seem to have fallen out of fashion somewhat (any

4.  musicbrainz.org
       pros:  this is 'the source' of all these ids and suc
       cons: afaik, these do not actually deref to any RDF;

also note, URIs like this


appear in http://lod.openlinksw.com/

i think this might be a mistake in xslt or something - not only do
these not actually deref to rdf, they return 404 from Musicbrainz -
perhaps there is some thing i am not understandin tho.  i believe the
'/music/' should be removed - then musibrainz.org handles the URI and
returns an html page.

As I mentioned before, we are giving a tutorial on music information
retrieval and the semantic web, see:


Put simply, what URIs do I tell people to use?


-Kurt J
Received on Sunday, 6 September 2009 12:21:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:15:59 UTC