MLQ (Media Library Query) file format and mime type proposal
frans.englich at telia.com
Thu Jun 22 17:18:59 EEST 2006
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> 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:
(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:
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
For example, one could use an XPointer fragment with an XPath scheme:
file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
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.
More information about the xdg