Terminal Zone: Website RFC

The following is the latest (June 2015) revision of various proposals for a music website. The purpose of the website is to help readers find new interesting new music in a wide range of genres. This iteration consists of a blog and a ratings database. The website will be maintained by a group of writers and editors invited from the community of critics and consumers that grew up around Robert Christgau's Expert Witness blog.

Home Page

The home page would focus on the blog (LIFO posts), with various links to static pages and the ratings database to the left or right (depending on theme) of the main content, as well as various widgets (e.g., news feed, Twitter feed, links to streamable music).

Blog

The blog can be implemented using off-the-shelf blog software, such as WordPress. This also gives us a usable user management and comments system, as well as a plugin interface. The theme should probably be customized. Plugins should be developed to interface with the ratings database.

Most posts will be diary entries by contributors. Recommended frequency is one post weekly, on a regular day, although we can be very flexible about that. Diary entries should mention any recent records heard, with brief comments and/or ratings but no formal review structure. Entries may also comment on concerts, books, movies, or anything else of likely interest. Entries will include links into the ratings database. Categories will be used to mark all diaries and individual contributors. Posts will also be tagged with keywords.

Diary writers are expected to add data to the ratings database, including ratings of old records to help provide a more comprehensive profile.

Other post types will be developed as opportunities permit.

WordPress makes a distinction between posts, which are cycled in LIFO blogs, and pages, which are intended to always be available. Several sets of pages are desired:

• Pages that provide an overview of the website, its mechanics, and contributors.
• A set of introductory guides -- usually lists of recommended albums under some keyword/genre heading.

Ratings Database

The ratings database will be developed using a RDBMS (like MySQL) and a proprietary website interface coded in PHP. The data will be encoded as UTF-8.

The database keeps track of ratings that various contributors have made of a common set of music albums. The essential tables are:

critic: describes an individual who rates albums.

• id
• uid: user id in blog
• name
• sort
• page: user page in blog
• keyw: user keyword in blog

album: describes a generic album.

• id
• artist
• title
• type: studio album, live album, compilation, ep, single
• sort: not clear how to do this
• rec_data: packed recording data
• rel_data: packed release data
• rel_date: initial release date
• meta: additional description information
• cg: cached grade

Encodings need to be established for the "data" sections. They are intended for display information, and are not meant for searches. This implies some loss of rigor in distinguishing between multiple releases: one has to decide whether ratings for two slightly variant releases should be combined or split. Excessive splitting fragments the ratings data, but some critics may wish to make distinctions between releases. The meta field can be used to explain splits, but isn't implemented so they can be joined.

We could add some sort of genre identifier. It wouldn't be very efficient to search on, but that might not be a problem. (One could, for instance, generate cached lists.)

grade:

• critic
• album
• grade: rating from 1-10 (or 1-100)
• comment
• ts: timestamp

Additional tables can be defined to provide a better browsing interface to the data. These aren't specified at present, but the following are possible examples:

• An artist table plus a table for joins against album would allow one to browse albums by artist. Normalizing the artist name from the album table produces excessive splits -- artist attributions often vary in trivial and useless ways. Separate tables also make it easier to map artists to multi-artist albums. An alternate approach might be to have separate person and group tables: useful if you want to keep more detailed personal information, but it makes search more complicated.
• A label table plus a table for joins against album would allow browsing or searching by label name.
• A genre table plus a table for joints against album (maybe also against artist). The main problem here is coming up with the genre taxonomy itself, especially a hierarchical one. Alternatively, this could be keyed against the blog keyword list and/or category taxonomy.
• A list table plus a table for joins against album. This could be used for an alternative implementation of genre search, but could also be used for more arbitrary collections, such as all the records in a particular series (e.g., Universal's "Millennium Collection") or all the records mentioned in some reference book. Table should allow for ordered or unordered lists, and for comments if needed.

External References

The website would be most useful if we could provide links to other web resources. This could be done either by adding encoded fields to above tables like album, or by adding a separate table for links and extra tables to join with album (and possibly other tables). Some example resources include Wikipedia, Discogs, Musicbrainz, All Music Guide, other music publications.

One could do a mix of both approaches, with the most standard links encoded in existing tables plus a separate table for tracking links that are mentioned in posts. The latter could, for instance, be used to generate a news feed widget.

We might wish to provide links to externally hosted music files. We would need a link table for this, with appropriate typecheck.

Twitter Interface

WordPress will automatically generate an RSS newsfeed, but it would also be useful to manually generate Twitter notices as posts are added or for special announcements. Conversely, we should have a widget for collecting our Twitter posts.

Same thing could conceivably be done for Facebook if we see the need.

Email notices are also valuable for concerned editors when the website changes. Need to look into this further. Would be good to have a digest option to control email bulk.

Business Plan

The website will initially be closely held on trust by its founders. When/if it seems to have real value, it can be incorporated and jointly owned by the founders and vested contributors. Vesting will be credited according to various metrics of contribution, to be determined.

We will need some sort of contributor agreement which grants the website a nonexclusive license to use contributions, while reserving all other rights to the contributor. (Alternatively, we could decide to use a standard free content license.)

We might consider setting up a writers' fund, which would collect contributions and distribute them to writers according to some committee and/or formula, to be determined.

The website would initially be implemented on Tom Hull's server, at no charge. All contributions are expected, initially anyhow, at no charge. A business plan for long-term operational costs is to be determined. Someone should look into possible revenue streams/models. We might set up an operational fund in parallel to the writers' fund.