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> &lt;<a href="mailto:internalerror@gmail.com">internalerror@gmail.com
</a>&gt; 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> &lt;<a href="mailto:frans.englich@telia.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">frans.englich@telia.com</a>&gt; 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>&gt; Hi,<br>&gt;<br>&gt; I'm one of the main authors of BMP 2 (still being worked on), and along the<br>&gt; way of reworking our library, i came across the idea of encoding library
<br>&gt; queries as URIs, which may look like this:<br>&gt;<br>&gt; &quot;query:///?artist=Air&amp;album=Moon%20Safari&quot;<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 &quot;query&quot;. 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 &quot;query&quot; ensured? Is it specified?</blockquote></span></div><div><div><br>Not at all yet but&nbsp; 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>&nbsp;</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;">

&gt; BMP 2 has a plugin archicture which is a small VFS on it's own, and we<br>&gt; treat certain things as &quot;containers&quot; (i.e. they &quot;contain&quot; URIs, like PLS<br>&gt; playlists, XSPF, M3U, etc).<br>&gt; Now i thought it might be not a bad idea to create a playlist format with
<br>&gt; these query URLs, and i've called it &quot;MLQ&quot; for media library query. In<br>&gt; theory, it's not even<br>&gt; application specific. The keys (identifiers), like artist, album, etc, are<br>&gt; all based on GStreamer tag identifiers. (They could be maybe adapted to
<br>&gt; <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>&gt; it seems insufficient and doesn't specify certain items, like musicbrainz
<br>&gt; metadata, which GST does).<br>&gt;<br>&gt; So i've called this file format &quot;MLQ&quot;, with the extension .mlq, created a<br>&gt; mime package file for it:<br><br>I think this highlights possible trouble. Anyone else who decides to
<br>invent &quot;query&quot; will get detected as &quot;Media Library Query List&quot;. 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>&nbsp;<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 &amp; 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(&quot;text&quot;),<br>

unless one wants to. It means the format is conceptually, on an &quot;abstract&quot;<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 &quot;music collections&quot; cannot be located as files, invent a scheme which can
<br>identify them on this &quot;abstract level.&quot;</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 &quot;making something up&quot;, 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>&nbsp;</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&nbsp; 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>&nbsp;</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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Frans<br></blockquote></div></div><div><span class="sg"><br><br>-- Milosz<br>

</span></div></blockquote></div><br>