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

I didn't know about tag URIs though, i'm taking a look at it now, thanks.

On 6/22/06, Milosz Derezynski <[email protected]> wrote:
>
>
>
> 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
>

_______________________________________________
gnome-multimedia mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-multimedia