<div>On 6/22/06, Frans Englich <<a href="mailto:frans.englich@telia.com">frans.englich@telia.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.)</blockquote><div> I think it is valid yes. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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: <a href="http://developer.kde.org/policies/uri-guidelines.xhtml">http://developer.kde.org/policies/uri-guidelines.xhtml </a> How is interoperability for "query" ensured? Is it specified?</blockquote><div> 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.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > 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 > <a href="http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec">http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec</a> , 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.</blockquote><div> Yeah well that is problematic for them haha :P   </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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: <a href="file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz">file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz</a>' and @album = 'Safari')) If "music collections" cannot be located as files, invent a scheme which can identify them on this "abstract level."</blockquote><div> 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 <a href="file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz">file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz </a> 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.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> However, I would first assess RDF as suggested in this thread, since it is designed exactly for things like this.</blockquote><div> 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.  </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Cheers,                 Frans </blockquote></div> -- Milosz