[Playlist] song identifiers

Kevin Marks kmarks at mac.com
Tue Mar 9 17:45:22 UTC 2004

On Mar 8, 2004, at 4:02 PM, Lucas Gonze wrote:

> 2. It does not address playlist portability at all. There are no
> references to files, URIs or URNs -- no support for canonical
> identifiers. This format is weak for resolving content, which is the
> key to this new format.
> --> Again something easily added at the top, if you want an xmlns or
> similar.

On Mar 8, 2004, at 3:24 PM, Matthias Friedrich wrote:

>> 2. The desire is to create a format with support for multiple means of
>> identifying content.  The playlist format should not be tied to the
>> lookup mechanism, but it should not prevent the use of any and all
>> lookup mechanisms.  I don't think we're short-circuiting this 
>> discussion
>> here by suggesting a basic format.
> Basically, there are two ways of identifying a track: using a resource
> locator (like file://) or using a canonical identifier (like the
> MusicBrainz URIs). Unfortunately, it isn't possible to know from an
> URI like "http://www.mafr.de/whatever" if this is a resource locator
> or canonical identifier. Therefore, we have to make this decision
> by other means when reading a playlist. In the example playlist, I
> introduced two properties (in RDF speech): pl:id and pl:cid (c for
> canonical).

The 'is this link a canonical ID' issue is readily resolved in the 
XHTML model by using a rel identifier of 'canonical'. Any href can have 
a space separated list of rel attributes attached to it, and these can 
be specified as an extension. See XFN as an example.

More information about the Playlist mailing list