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

On 6/22/06, Frans Englich <[email protected]> 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

_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg