[Playlist] criteria nodes

Lucas Gonze lgonze at panix.com
Wed Mar 10 18:03:24 UTC 2004


On Wednesday, Mar 10, 2004, at 11:46 America/New_York, ian c rogers 
wrote:

> Unless I'm missing the point, this seems to solve a different problem. 
>  I think of the criteria nodes as a filter on all the music a player 
> knows about, not a way to identify a particular song.  I'd still 
> prefer to identify a particular song by a number of methods, from 
> unique identifier down to metadata.

Yeah, I have convinced myself that this approach is wrong.  Maybe when 
we have definite syntax for the criteria and fuzzy match elements there 
will be enough in common to factor the shared items, but until then 
there's no point.

- Lucas



>
> ian
>
>
> Lucas Gonze wrote:
>
>> Thinking about criteria nodes, I realized that they have everything 
>> in common with our concept of fuzzy identifiers.  A criteria node 
>> does a query on available files, then figures out which one(s) to 
>> use.  A fuzzy identifier does the same thing, but extends it to 
>> resources out on the internet.
>>
>> So what I want to suggest is that when you give the address of the 
>> song resource, you can give a fragment identifier which points to a 
>> criteria node in the same document.
>>
>> Addressing a song known only by URI:
>> <songReferenceInPlaylist songAddressURI="http://foo.com/bar.mp3"/>
>>
>> Addressing a song known only by filename:
>> <songReferenceInPlaylist songAddressURI="file:///foo/bar.mp3"/>
>>
>> Addressing a song known only by criteria:
>> <songReferenceInPlaylist 
>> songAddressURI="#fragmentIdentifierOfCriteriaNode"/>
>> ...then later in the same document...
>> <Criteria rdf:about="fragmentIdentifierOfCriteriaNode" >
>>    <!-- stuff here giving enough info to find the file(s) -->
>> </Criteria>
>>
>> What this accomplishes is that it solidifies the identifier syntax, 
>> lets us incorporate both simple and complex identifiers, and supports 
>> both iTunes-like 'smart' playlists and fuzzy lookups of the kind that 
>> Kevin Marks has been advocating.  A very trivial player could choose 
>> to only support file URIs, a slightly more sophisticated one could 
>> support HTTP URLs, and an industrial strength player could support 
>> criteria.  A simple player like mpg123 could pipe the content through 
>> a content resolver which converts the criteria references to file 
>> references, while a superpowered player like Winamp could handle the 
>> entire operation on its own.
>>
>> Please don't get hung up on my choice of identifiers or attribute 
>> syntax.  The important things are that the address of the song 
>> resource MAY be a fragment identifier, if there is an address which 
>> is a fragment identifier then there MUST be a criteria node in the 
>> same document with that fragment name, and if there is an address 
>> which a player can't resolve it MUST NOT choke and die.
>>
>> - Lucas
>>
>>
>> _______________________________________________
>> Playlist mailing list
>> Playlist at lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/playlist
>
> _______________________________________________
> Playlist mailing list
> Playlist at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>




More information about the Playlist mailing list