VorbisComment: Difference between revisions

Revision as of 14:00, 13 September 2007

The goal for this page is to discuss how to improve the Vorbis Comment specification.

Field names

Some proposals for extra field names:

Ogg Vorbis Comment Field Recommendations
Proposals for extending Ogg Vorbis comments
Spotlight importer (not a proposal, but noteworthy implementation)

Comments are intended to be free-form, but for the purposes of interoperability, it is helpful to define tag sets for particular applications, and provide some guidelines for machine parsing.

Dates and time

The goal is to specify a format for describing dates.

Proposals

The date format for any field describing a date must follow the ISO scheme: YYYY-MM-DD or shortened to just YYYY-MM or simply YYYY.

We have been recommending this usage with the DATE tag for some time. It is proposed that the spec be amended to include this information for machinability.

The time format for any field except track duration must be specified with leading T and ending with a time zone. Schemas with and without dates: YYYY-MM-DDTHH:MM:SS+TS THH:MM+TZ

Improving license data

The goal is to provide a method for proclaiming license and copyright information (basically clarifying ‘distribution rights (if any) and ownership’).

The specification document describes LICENSE and COPYRIGHT fields. But is not clear enough about whether these should be machine-readable.

We should consider working together with Creative Commons to have complementary and interlinked information on the CC and Xiph wikis. Refer to the Ogg page in the CC wiki.

New RIGHTS field name proposal

One proposal is to replace the COPYRIGHT and LICENSE field names with RIGHTS. RIGHTS must be a human-readable copyright statement. Basic example:

But this is not machine-readable. Adding two complementary field names should do the trick: RIGHTS-DATE, describing the date of copyright; and RIGHTS-URI, providing a method for linking to a license. Software agents can assume that multiple songs uses the sameURIs, such as in the case for Creative Commons. Full example:

Software such as for multimedia management and playback are encouraged to display the RIGHTS statement as a linked phrase using RIGHTS URI.

RIGHTS DATE does not need to be displayed as it is required in the human readable version by international copyright agreements. RIGHTS DATE can be used to determine when a copyrighted work falls under the public domain and related matters. (The Beatles' copyright on their original studio recordings (not the remixes) are soon expiering. So mechanisms such as the RIGHTS DATE are indeed required in music management and filesharing software!)

To remain machine-readable it would be required to have at most one instance of each RIGHTS field name. All fields would of course remain optional.

The Dublin Core Metadata Initiative recommends the use of ‘rights’ to describe license and copyright matters. The web feed format Atom 1.0 has implemented a rights element in their specification.

Improving excisting fields proposal

Similar to the DATE tag above, we have generally recommended that a URL uniquely identifying the license be included in the LICENSE field to allow machine identification of the license. This is in agreement with the proposal in the CC wiki. Since the COPYRIGHT field is a human-readable statement of the copyright, like the proposed RIGHTS tag above, some people include a license url there. Therefore if a url can't be found in a LICENSE tag if any, applications should use one from the COPYRIGHT tag, if any. Contact information for verification, attribution, relicensing, etc. can be obtained from the COPYRIGHT field, but CC also recommend a separate CONTACT tag for this information. This is reasonable, so we propose it be included.