Publishing your own music on the web is an unrealistically big job. It’s easy if you just want to dump an MP3 somewhere, but good luck if you want to do a solid job on SEO, viral uptake, and the conventions of open media. And because it’s so time consuming, almost nobody does it. You wouldn’t have time left over for the music.
So I’m looking for ways to streamline the process, and to begin with I have compiled a checklist of work items and features. This list is an ideal; I have never done all of these for any one song. Even though I had most of this in my head it still took quite a while to compile and tidy up the list, so I figured it would be useful to others if I published it. I’d appreciate comments, corrections and improvements.
Files
- Image file for sheet music
- Media files
Blog entry
- Composition metadata:
- Song title
- Song composer
- Publication date
- Links to all media files
- Link to source web site for composition
- Media player to render the song in-place
- Annotation about the music or recording
- Inline image for sheet music, linked to source web site
Viral spread
- Code to copy and paste for embedding a badged version of the media in a third party page like a Myspace profile.
- A direct URL for the media file.
- A statement that direct linking or embedding is fine.
- Buttons to add to del.icio.us, Digg This, etc.
License statements
- Unstructured textual license statement for humans to read on the web.
- SEO: search-engine friendly license statement in the HTML. Spiders have to be able to recognize that a song file is under a Creative Commons license.
- Identify search engines that track Creative Commons music.
- Document what methods they use to determine whether a file is under a Creative Commons license.
- Creative Commons requirements
- Web page where the work metadata, including verification information, may be found.Verification metadata is currently defined in principle but probably not used in practice. Verification metadata means :
A content-derived identifier (e.g. SHA1 hash) or other independently verifiable identifier
.
A SHA1 hash of the media file would have to be applied to the final file, with all tags exactly as they will be at final publication. Given that the URL of the web page containing work metadata, including the content-derived identifier, has to be created and embedded in the media file before the media file can be finalized, the publication process must be:- Create stub web page for work metadata. Get a stable public URL for this.
- Embed link to work metadata page in media file.
- Compute SHA1 or other content-derived identifier for media file.
- Embed content-derived identifier in work metadata page.
- License URL. For example, http://creativecommons.org/licenses/by/2.
Creative Commons reference:
- Web page where the work metadata, including verification information, may be found.Verification metadata is currently defined in principle but probably not used in practice. Verification metadata means :
I’m tracking these requirements too (for my upcoming album, which will be available online). It’s similar to your list, but because it’s an album-website and not only song-entries on a blog, there’s also cross-linking between related songs.
A generic model of these cross-linking requirements–some of which might be applicable to blogging, could include: links to playlists that include this song; previous song / next song tracking; and a general sense of sequence (e.g., play all Lucas’ songs from July, order by date).
Also, what you have as “annotations” could be split into some categories, like credits, lyrics, recording date, recording location, instruments used, etc. Credits might include other musicians, producers, composers, etc.
Also, you might think about “annotations” in terms of something like the Wikipedia entry on Purple Haze, e.g., both in terms of the way it has an internal structure of “types” of information / data, and also in terms of it’s design as a hypertext document with cross-linking.
(Of course, I know: your blogging, not wiki-ing. . .)
For example, I haven’t quite understood how you’re choosing songs. And, I could imagine each song referencing “indexes” that provide both more context for how your collecting songs together, and also cross-referencing between the songs and their sources (be they sources of the sheet music, composer names, original instruments, year, country of origin, etc.).
These are great ideas, Jay.
I see a potential problem in how many good ideas you propose for new fields — the problem definition is open ended. Ultimately this description should end up encoded into software, and a page with 5000 fields in it isn’t very useful. So how to set a limit and keep the thing a reasonable size? And how to keep the amount of work down?
You are bringing together a lot of different goals, and an important thing to recognize is that you’re dealing with users, content and context in a domain (music) where there are different types of users (inidividual and collective artists, music collectors, fans, etc.), different types of content (pop songs, albums, classical tracks, new forms, etc.), and a context (the WWW) that’s totally multifaceted. So, there are a lot of ways to answer your question.
But, getting very abridged and sofrware-oriented, you are basically talking about software that, generically, does content and asset management. And, while the devil is in the details, a generic way to handle this is based on a template system: different types of content / assets have different templates, and different types of users may use different levels of templates (e.g., minimal data or lots of data templates).
And, ideally, people can add their own templates to meet their own needs, e.g., “open ended” gets handled as “extensible.”
So, for example, my music template and your music template can be different, because we have different approaches to how we want to communicate about our musics, the music forms themselves are different, and we probably also have some different ideas about how we want to web our musics.
In terms of effort, the system would ideally allow data / info entered for related bits of content / assets to be shared, e.g., you enter the song title in one place and it ends up in each file and in the annotations. Asset-oriented data like song length and file size could be automatically extracted from files into the annotations. Contents-oriented data / info like liencensing could be automatically extracted from text annotations into the files.
Interesting list. I agree with Jay that this is bringing a lot of different ideas together. I think it may help to analyze what is the bare minimum a user will have to input in order to generate all these features. It also depends a lot on the platform used to do it. Something like Drupal could automate all of this, but how could it be automated or made simpler for people without a CMS?
Something I find interesting post facto about this project is the way that it is bringing ideas to the surface, like using Drupal as a platform for self-publishing music.
The goals themselves are indeed a source of confusion. This problem isn’t defined cleanly enough. For example, I can’t say what *isn’t* part of the solution.