I didn't know about tag URIs though, i'm taking a look at it now, thanks.<br><br><div><span class="gmail_quote">On 6/22/06, <b class="gmail_sendername">Milosz Derezynski</b> <<a href="mailto:internalerror@gmail.com">internalerror@gmail.com
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br><br><div></div><div><span class="q"><span class="gmail_quote">
On 6/22/06, <b class="gmail_sendername">Frans Englich</b> <<a href="mailto:frans.englich@telia.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">frans.englich@telia.com</a>> wrote:</span><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:<br>> Hi,<br>><br>> I'm one of the main authors of BMP 2 (still being worked on), and along the<br>> way of reworking our library, i came across the idea of encoding library
<br>> queries as URIs, which may look like this:<br>><br>> "query:///?artist=Air&album=Moon%20Safari"<br><br>(Is that at all a valid URI? I'm not sure.)</blockquote></span></div><div><div><br>I think it is valid yes.
<br><br></div></div><div><span class="q"><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
<br>
trouble. Especially, for such a generic name as "query". This document<br>discusses this further:<br><br><a href="http://developer.kde.org/policies/uri-guidelines.xhtml" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://developer.kde.org/policies/uri-guidelines.xhtml
</a><br><br>How is interoperability for "query" ensured? Is it specified?</blockquote></span></div><div><div><br>Not at all yet but because of that i'm asking on those 2 lists here now (xdg<br>and gnome-multimedia), and furthermore i made some interoperability
<br>proposals, just 2 totally off my head but not totally out of place either.<br> </div></div><div><span class="q"><br><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<br>> treat certain things as "containers" (i.e. they "contain" URIs, like PLS<br>> playlists, XSPF, M3U, etc).<br>> Now i thought it might be not a bad idea to create a playlist format with
<br>> these query URLs, and i've called it "MLQ" for media library query. In<br>> theory, it's not even<br>> application specific. The keys (identifiers), like artist, album, etc, are<br>> all based on GStreamer tag identifiers. (They could be maybe adapted to
<br>> <a href="http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec
</a> , but<br>> it seems insufficient and doesn't specify certain items, like musicbrainz
<br>> metadata, which GST does).<br>><br>> So i've called this file format "MLQ", with the extension .mlq, created a<br>> mime package file for it:<br><br>I think this highlights possible trouble. Anyone else who decides to
<br>invent "query" will get detected as "Media Library Query List". All that's<br>needed to fix this is to use URIs properly.</blockquote></span></div><div><div><br>Yeah well that is problematic for them haha :P
<br> <br>
</div></div><div><span class="q"><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
<br>dependent. Music players & hardware(ipods, music players, music sharing
<br>sites, and so on) is quite popular in western societies right now, but next<br>year it's something different. Technologies, such as a URI scheme, shouldn't<br>be hard coded on a specific use, it should be generic.<br>
<br>Re-use existing technologies. There's plenty of work and research on meta data<br>and querying data. Here's my suggestions:<br><br>Express the format in XML. This has nothing to do with XML files("text"),<br>
unless one wants to. It means the format is conceptually, on an "abstract"<br>level, described in XML which in turn opens up the door for all methods XML<br>has.<br><br>For example, one could use an XPointer fragment with an XPath scheme:
<br><br><a>file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz</a>' and @album<br>= 'Safari'))<br><br>If "music collections" cannot be located as files, invent a scheme which can
<br>identify them on this "abstract level."</blockquote></span></div><div><div><br><br>That is actually a very good idea (to use an XPath), but then again i would be abusing<br>the file:/// scheme. What should it point to? Even if it would point to the physical location
<br>of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,<br>so <a>file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
</a><br>and @album='Safari')), then i would be basically still "making something up", as you cannot<br>pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.<br><br>Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
<br>query:/// in this way system wide.<br><br>What i'm up to is that while your proposal with file seems<br>more sane (and XPath/XPointer is certainly better than using a GET string, i might really<br>consider changing the query:/// URI to use that), it actually is no different. Those kinds of
<br>file:/// URIs would need special treatment as well, and in fact, would cause even more headache<br>possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.<br> </div></div><div><span class="q">
<br><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<br>designed exactly for things like this.</blockquote></span></div><div><div><br>Well RDF possibly, but i think i will never in my life use SPARQL. I took a look at it
<br>and i want these things if not neccessarily, then at least possibly, human editable,<br>buit SPARQL is just way beyond the comprehension of taking a quick glance at the<br>file and making some corrections.<br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Cheers,<br><br> Frans<br></blockquote></div></div><div><span class="sg"><br><br>-- Milosz<br>
</span></div></blockquote></div><br>