THE CONTEXT: Let's say you're putting together a website for a band who's released several albums and wants web pages for each album and each song. To simplify things (and future-proof your URLs), you've decided to omit file extensions from your URLs, so you need a directory for each album and a directory for each song.
THE QUESTION: What are some best practices for naming directories for songs and albums? What algorithm can yield durable, maintainable URLs?
EXAMPLES:
First, let's use the Beatles' album "Let It Be" as an example:
1) /albums/Let It Be/ -- spaces are unfriendly to UNIX
2) /albums/LetItBe/
3) /albums/Let_It_Be/
4) /albums/let_it_be/
5) /albums/let-it-be/
6) /albums/letitbe/
7) /albums/1970/let_it_be/
8) /1970/albums/let_it_be/
9) /1970/let_it_be/ -- won't work if there's a song of the same name
10) /let_it_be/ -- won't work if there's a song of the same name
11) /albums/album13/ -- assuming it was their 13th album
12) /albums/13/
14) /albums/1970/13/
15) /albums/1970/album1/ -- first album of 1970
16) /albums/1970/01/
17) /albums/1970/05/08/let_it_be/ -- released may 8th
18) /albums/1970/05/08/ --doesn't support multiple albums per day
19) /1970/05/08/albums/let_it_be/
20) /albums/34567/ -- some arbitrary (but permanent) album/release id
Okay, now let's consider the song "Get Back", on that same album:
1) /albums/let_it_be/songs/get_back/
2) /albums/let_it_be/get_back/
3) /albums/let_it_be/song12/ -- it's the 12th song on the album
4) /albums/let_it_be/12/
5) /albums/let_it_be/12_get_back/ -- track number plus song title
6) /let_it_be/get_back/
7) /songs/get_back/
8) /songs/g/get_back/ -- "g" is first letter in get_back
9) /songs/1970/get_back/ -- song's release (or recording or authoring) year
10) /songs/1970/07/03/get_back/ -- includes full date (of recording or authoring or release)
Notice how the first six song examples all have the song ("Get Back") lying "within" the album ("Let It Be"), and the next four have the song "outside" of the album. This is something we need to consider: the relationship of songs to albums. Does a song naturally "belong" to an album, or is it merely "used" by an album?
I would argue the latter. Here's why:
Placement of songs "within" an album suggests that each song belongs to exactly one album. This isn't always the case, however, especially if you're using the word "album" to refer to any collection of songs (studio albums, compilations, live sets, sampler CDs, soundtracks, etc.). With the "song within an album" strategy, how would you deal with the same song appearing on multiple "albums"?
Another thing to consider is versions of songs:
1) "Get Back" on "Beatles 1" -- might be the same as the album cut
2) "Get Back" on "Past Masters Vol 3" -- different version, since it's longer than the album cut
3) "Get Back" on "The Get Back Journals" -- seven versions of this song!
If you're just dealing with mp3s, then sure, using track numbers and a separate mp3 for each track is a great idea. It's simple and flexible. The seven versions of "Get Back" on the "...Journals" album would be easy to find. Even if the "Get Back" on "Beatles 1" is exactly the same as the album version, you could still have a separate mp3 for it. Since mp3s' contents tend to be static, the only real "cost" of having multiple copies of the same song version is disk space, which these days is not a big deal.
However, if you're dealing with song and album web pages, then you're dealing with changing content and an expectation of URL permanence. You need to keep the data consistent and easy to find for both the user and the maintainer. You need to avoid replication of data and keep the URLs as stable (flexible, readable, scalable, predictable) as possible. If the lyrics for every "Get Back" version are always the same, then there should be *one* file containing those lyrics, not multiple files. You need to reuse data instead of copying it.
Also, consider unreleased songs. They aren't within albums today, but they might be someday. When that day comes, you shouldn't have to change the url for the song. This reinforces the idea that songs should be "outside" of albums, that album data can refer to song data, but not actually "posess" that data. This suggests a sibling rather than parental relationship:
bad:
/albums/let_it_be/get_back/
good:
/albums/let_it_be/
/songs/get_back/
The more I think about it, the more this sibling relationship makes sense. An album doesn't really "own" a song. There's isn't really a one-to-many relationship. Two albums can have just as much "ownership" of a song, and assigning a "primary owner" or even "first owner" doesn't make sense. Think of all the songs released as singles, and then added to albums as bonus tracks. Think of all the albums with different versions, for that matter. UK versions and US versions. Album versions with the same songs, but different track orders. Think about EPs and Singles, for that matter. Can an album "own" a song if that song is also on a single? Not really. The fact is, albums, EPs, singles, and unreleased collections all *share* songs. The songs exist outside of the collections.
So, if we accept that songs are "outside" of albums, then we need to pick a a structure like this:
a) /songs/get_back/ -- lots of subdirectories in one directory!
b) /songs/g/get_back/ -- helps split up the tree, but seems a little hacky
c) /songs/1968/get_back/ -- let's say 1969 was the authoring date
d) /songs/1969/get_back/ -- let's say 1970 was the recording date
e) /songs/1970/get_back/ -- initial release date (copyright date?)
f) /songs/1988/get_back/ -- release date for version on "Past Masters vol 3"
I think "a" is the simplest approach, but it results in hundreds or even thousands of directories in the "songs" directory. This would be perfectly fine if you're using a database to serve the site (where the directories are actually virtual), but not if you have static pages. Therefore, thought should be given to splitting up the songs into multiple subdirectories. We can do it alphabetically (first letter, first two letters, ???) or by date. If we do it by date, then which date should we use?
Whatever method we pick, it should be easy to apply, and should make it easy to find a given song when we need to edit it. This is where I'm a bit stumped, especially when I think about the next question:
What about versions?
Let's say there are 10 different versions of "Get Back", some live, some studio, some recorded on different dates, some on the same date... How would you organize each of these versions, in terms of directories?
Let's say there's a version (the third) recorded live on Christmas 1969. Where would we put data about that version? Here are some possibilities:
1) /songs/get_back/ -- all versions discussed on one page
2) /songs/get_back/version3.html -- exposes file extension
3) /songs/get_back/version3/ -- subdir for each version
4) /songs/get_back_version3/ -- each version treated as a standalone song
5) /songs/get_back_03/ -- shorter version id, prevents songs from ending in _#
6) /songs/get_back/03/
7) /songs/get_back/live19691225/ (verbose version name)
8) /songs/get_back/1969/12/25/
9) /songs/get_back/1969/12/25/version3/
Which of these options is most likely to be usable and still around 20 years from now? Which makes it easy to add more versions later without shifting around page contents?
These are hard questions, and I'd love to hear your thoughts!
Thanks!
Travis
THE QUESTION: What are some best practices for naming directories for songs and albums? What algorithm can yield durable, maintainable URLs?
EXAMPLES:
First, let's use the Beatles' album "Let It Be" as an example:
1) /albums/Let It Be/ -- spaces are unfriendly to UNIX
2) /albums/LetItBe/
3) /albums/Let_It_Be/
4) /albums/let_it_be/
5) /albums/let-it-be/
6) /albums/letitbe/
7) /albums/1970/let_it_be/
8) /1970/albums/let_it_be/
9) /1970/let_it_be/ -- won't work if there's a song of the same name
10) /let_it_be/ -- won't work if there's a song of the same name
11) /albums/album13/ -- assuming it was their 13th album
12) /albums/13/
14) /albums/1970/13/
15) /albums/1970/album1/ -- first album of 1970
16) /albums/1970/01/
17) /albums/1970/05/08/let_it_be/ -- released may 8th
18) /albums/1970/05/08/ --doesn't support multiple albums per day
19) /1970/05/08/albums/let_it_be/
20) /albums/34567/ -- some arbitrary (but permanent) album/release id
Okay, now let's consider the song "Get Back", on that same album:
1) /albums/let_it_be/songs/get_back/
2) /albums/let_it_be/get_back/
3) /albums/let_it_be/song12/ -- it's the 12th song on the album
4) /albums/let_it_be/12/
5) /albums/let_it_be/12_get_back/ -- track number plus song title
6) /let_it_be/get_back/
7) /songs/get_back/
8) /songs/g/get_back/ -- "g" is first letter in get_back
9) /songs/1970/get_back/ -- song's release (or recording or authoring) year
10) /songs/1970/07/03/get_back/ -- includes full date (of recording or authoring or release)
Notice how the first six song examples all have the song ("Get Back") lying "within" the album ("Let It Be"), and the next four have the song "outside" of the album. This is something we need to consider: the relationship of songs to albums. Does a song naturally "belong" to an album, or is it merely "used" by an album?
I would argue the latter. Here's why:
Placement of songs "within" an album suggests that each song belongs to exactly one album. This isn't always the case, however, especially if you're using the word "album" to refer to any collection of songs (studio albums, compilations, live sets, sampler CDs, soundtracks, etc.). With the "song within an album" strategy, how would you deal with the same song appearing on multiple "albums"?
Another thing to consider is versions of songs:
1) "Get Back" on "Beatles 1" -- might be the same as the album cut
2) "Get Back" on "Past Masters Vol 3" -- different version, since it's longer than the album cut
3) "Get Back" on "The Get Back Journals" -- seven versions of this song!
If you're just dealing with mp3s, then sure, using track numbers and a separate mp3 for each track is a great idea. It's simple and flexible. The seven versions of "Get Back" on the "...Journals" album would be easy to find. Even if the "Get Back" on "Beatles 1" is exactly the same as the album version, you could still have a separate mp3 for it. Since mp3s' contents tend to be static, the only real "cost" of having multiple copies of the same song version is disk space, which these days is not a big deal.
However, if you're dealing with song and album web pages, then you're dealing with changing content and an expectation of URL permanence. You need to keep the data consistent and easy to find for both the user and the maintainer. You need to avoid replication of data and keep the URLs as stable (flexible, readable, scalable, predictable) as possible. If the lyrics for every "Get Back" version are always the same, then there should be *one* file containing those lyrics, not multiple files. You need to reuse data instead of copying it.
Also, consider unreleased songs. They aren't within albums today, but they might be someday. When that day comes, you shouldn't have to change the url for the song. This reinforces the idea that songs should be "outside" of albums, that album data can refer to song data, but not actually "posess" that data. This suggests a sibling rather than parental relationship:
bad:
/albums/let_it_be/get_back/
good:
/albums/let_it_be/
/songs/get_back/
The more I think about it, the more this sibling relationship makes sense. An album doesn't really "own" a song. There's isn't really a one-to-many relationship. Two albums can have just as much "ownership" of a song, and assigning a "primary owner" or even "first owner" doesn't make sense. Think of all the songs released as singles, and then added to albums as bonus tracks. Think of all the albums with different versions, for that matter. UK versions and US versions. Album versions with the same songs, but different track orders. Think about EPs and Singles, for that matter. Can an album "own" a song if that song is also on a single? Not really. The fact is, albums, EPs, singles, and unreleased collections all *share* songs. The songs exist outside of the collections.
So, if we accept that songs are "outside" of albums, then we need to pick a a structure like this:
a) /songs/get_back/ -- lots of subdirectories in one directory!
b) /songs/g/get_back/ -- helps split up the tree, but seems a little hacky
c) /songs/1968/get_back/ -- let's say 1969 was the authoring date
d) /songs/1969/get_back/ -- let's say 1970 was the recording date
e) /songs/1970/get_back/ -- initial release date (copyright date?)
f) /songs/1988/get_back/ -- release date for version on "Past Masters vol 3"
I think "a" is the simplest approach, but it results in hundreds or even thousands of directories in the "songs" directory. This would be perfectly fine if you're using a database to serve the site (where the directories are actually virtual), but not if you have static pages. Therefore, thought should be given to splitting up the songs into multiple subdirectories. We can do it alphabetically (first letter, first two letters, ???) or by date. If we do it by date, then which date should we use?
Whatever method we pick, it should be easy to apply, and should make it easy to find a given song when we need to edit it. This is where I'm a bit stumped, especially when I think about the next question:
What about versions?
Let's say there are 10 different versions of "Get Back", some live, some studio, some recorded on different dates, some on the same date... How would you organize each of these versions, in terms of directories?
Let's say there's a version (the third) recorded live on Christmas 1969. Where would we put data about that version? Here are some possibilities:
1) /songs/get_back/ -- all versions discussed on one page
2) /songs/get_back/version3.html -- exposes file extension
3) /songs/get_back/version3/ -- subdir for each version
4) /songs/get_back_version3/ -- each version treated as a standalone song
5) /songs/get_back_03/ -- shorter version id, prevents songs from ending in _#
6) /songs/get_back/03/
7) /songs/get_back/live19691225/ (verbose version name)
8) /songs/get_back/1969/12/25/
9) /songs/get_back/1969/12/25/version3/
Which of these options is most likely to be usable and still around 20 years from now? Which makes it easy to add more versions later without shifting around page contents?
These are hard questions, and I'd love to hear your thoughts!
Thanks!
Travis