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

["Milosz Derezynski" <internalerror gmail com>]

On 6/22/06, Frans Englich <frans englich telia com> wrote:

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.)

I think it is valid yes.

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?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> 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.

Yeah well that is problematic for them haha :P
 

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."

That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[ artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

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

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans

-- Milosz