MLQ (Media Library Query) file format and mime type proposal

[Frans Englich]

On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

First of all, one can't simply invent ones own URI scheme, because it causes 
trouble. Especially, for such a generic name as "query". This document 
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to 
invent "query" will get detected as "Media Library Query List". All that's 
needed to fix this is to use URIs properly.

However, I wouldn't invent a new URI scheme for this, it's too context 
dependent. Music players & hardware(ipods, music players, music sharing 
sites, and so on) is quite popular in western societies right now, but next 
year it's something different. Technologies, such as a URI scheme, shouldn't 
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data 
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"), 
unless one wants to. It means the format is conceptually, on an "abstract" 
level, described in XML which in turn opens up the door for all methods XML 
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album 
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can 
identify them on this "abstract level."

However, I would first assess RDF as suggested in this thread, since it is 
designed exactly for things like this.

In this way one doesn't have to invent a whole query language for music files. 
That's like inventing C++ for writing games, C++ for fixing bugs in word 
processors, C++ for writing editors, and so on.


Cheers,

		Frans