The Music of Fluidinfo II

I pushed an update to the abouttag.py library last night; it now includes some conventions and normalization for some music-related items. This supports work by Eric Seidel (@gridaphobe), who is looking at importing data from MusicBrainz to Fluidinfo.

These are similar (but not identical) to the ideas I proposed previously in the post The Music of FluidDB I: Albums, Tracks and Songs.

The first three kinds of things covered are works—named albums and named tracks respectively. As with books, this conceptual work seems like the single most important level to represent in Fluidinfo. So there may be many different issues, editions and pressings of The Dark Side of the Moon by Pink Floyd, but there is only one work. Even more clearly, Billie Holliday may have recorded God Bless the Child a number of times (I’m playing through several as I type this) , but there is only one conceptual work God Bless the Child sung by Billie Holliday.

• Albums (as works). The convention for this, called album-u, is similar, but not identical to the convention for books, having the general form

  album:name of album (artist)

  The name of the album and the artist are normalized using the usual normalize function from abouttag.py, removing some punctuation, regularizing spacing and converting to lower case, but not removing accents. (I think it’s increasingly clear that removing accents was a mistake in book-1; I’m now recommending using the relatied book-u conventions, which is like book-1 except that it preserves accents.)

  The other main difference between the book-u convention and the album-u convention is that in the case of books, multiple authors are consolidated into a standard list, separated by semicolons (in fact, a semicolon followed by a space). This works less well for music, where artists take more different forms Diana Ross and the Supremes, Pink Floyd, John Renbourn and Stefan Grossman, Crosby, Stills, Nash & Young etc. Since MusicBrainz, in particular, has a well-defined artist field, which is supposed to be the official recording credit, Eric is just planning to standardize that.

  Example usage is:

  from abouttag.music import album
  
  print album(u"Solilaï", u'Pierre Bensusan')
  print album(u"Déjà   Vu", u'Crosby, Stills, Nash & Young')
  

  producing

  album:solilaï (pierre bensusan)
  album:déjà vu (crosby stills nash & young)

  Of course, we may also create objects for paricular releases of an album, but those would use a different convention.

• Named Tracks / Recorded Songs. These are have a form that is identical to albums except that they use track: as the prefix. Again, two different recordings of the same song get consolodated into a single (conceptual) track (convention track-u).

  Example usage is:

  from abouttag.music import track
  
  print track(u'Bamboulé', u'Bensusan and Malherbe')
  
  print track(u'''Archie Campbell/Marjorie Campbell/Miss Lyall's '''
              u'''Strathspey/Miss Lyall's Reel/The St Kilda Wedding''',
              u'The Cast'),
  

  producing

  track:bamboulé (bensusan and malherbe)
  track:archie campbell marjorie campbell miss lyalls strathspey miss lyalls reel the st kilda wedding (the cast)

• Recordings. In the case of conceptual tracks, it is particularly clear that same artist may record the same track several times. Happily, there is a standard identifier for such recordings of tracks, the International Standard Recording code. This is 12-character code, usually formatted for print as CC-XXX-YYY-NNNNN, where CC is a registrant country code, XXX is a registrant code, UU is the last two digits of the registration year and NNNNN identifies the recording.

  Despite minor misgivings on my part (I would have chosen to keep the dashes, since Fluidinfo generally favours humans over machines), we have chosen to standardize this in the form isrn:CCXXXYYYNNNNN.

  Examples:

  from aboutag.music import isrc_recording
  
  print isrc_recording(u'US-PR3-73-00012')
  print isrc_recording(u'uspr37300012')
  

  produces

  isrc:USPR37300012
  isrc:USPR37300012

• Artist. The artist is simply identified by artist:name, where name is normalized as usual. Since accents are preversed, metal fans need not fear for their heavy metal umlauts (a.k.a. röck döts). For example:

  from aboutag.music import artist
  
  print artist(u"Crosby, Stills, Nash & Young")
  print artist(u"Motörhead")
  

  produces:

  artist:crosby stills nash & young'
  artist:motörhead'

Disambiguation, search and the related-to tag¶

I’ll do a longer post on this shortly, but an interesting an useful metaconvention is emerging within Fluidinfo.

I think there is a slightly reluctant but growing consensus within the Fluidinfo community that it makes sense to use about tags that exhibit pretty good uniqueness—I’ve suggested that at worst we should probably aim for conventions that mean that when we deal with a million objects we are unlikely to get a clash in about tags, not just within the list but with anything else anyone is ever likely to put into Fluidinfo.

At the same time, there is natural desire to make it easy for humans to navigate Fluidinfo via the natural about tags. Mercury the planet and mercury the element share the natural about tag mercury, but there is clearly a problem if we just stick information (like mass, or radius) on the object with about tag mercury. The about tags planet:mercury and element:mercury are much less ambiguous. (Unfortunately, in the early days I actually used planet:Mercury and element:Mercury; in my copious spare time, I’ll probably move the data over to the lower-case versions).

The emerging meta-convention is:

Store data on the most specific, unambiguous object reasonably available

• book:animal farm (george orwell)
• album: dark side of the moon (pink floyd)
• element:mercury etc.

Help humans by also using the more natural, ambiguous objects

• animal farm
• dark side of the moon
• mercury

as disambiguation nodes (à la Wikipedia), adding appropriate related-to tags that point to the various more specific items. The convention for these is that they are sets of about tag strings.

As an example, MusicBrainz might add a tag

musicbrainz.org/related-to=["album:dark side of the moon (pink floyd)"]

to the object with about tag dark side of the moon.

Similarly, an the Fluidinfo object with the about tag money might find itself tagged with (for example):

musicbrainz.org/related-to=["track:money (pink floyd)", "track:money (the flying lizards)",
                            "track:money (michael jackson)", "album:money (kfmdm)"]
miro/books/related-to=["book:money (martin amis)"]
imf.org/related-to=["economics:money"]

and so forth. This looks like it could have legs.

The key principle is: put the data on specific object at the right conceptual level, disambiguating as early as possible, i.e. don’t start by assuming that money could only refer to the Pink Floyd song, and use a convention that works well for all objects in the class of interest. Similarly, if you want put data that’s only applicable to a particular recording of that song, stick it on a more specific object (in this case, perhaps the isrn: object), probably adding a related-to tag pointing from the track: object to the various isrn: objects.

My only problem with this convention is that the term related-to sounds symmetrical, whereas it’s being use in a fairly directed way. Perhaps could-refer-to would be better.