2007/2/1, John Stowers &lt;<a href="mailto:john.stowers@gmail.com">john.stowers@gmail.com</a>&gt;:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><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;"><div><div><br>Another thing you don&#39;t seem to have covered. How would an application determine what files have emblem X? Or how do an app set emblem X on a file (or generally an uri)?
<br><br>This doesn&#39;t strictly have to be part of the proposal though...</div></div></blockquote></span><div><br>Yeah I have intentionally left that out - in this case. I tried to
elaborate a bit in the section on &quot;Relationship to tags&quot; to clarify
this spec only covers the definition of emblems.<br>
<br>
While that might make this spec a bit simple I see it as a necessary
first step. To be honest I was going to see how Wasapi pans out and
then start to think about a common DBus API for associating metadata
with files at a later date. Such an api could be<br>
<br>
AttachKeyword(keyword, uri)<br>
AttachEmblem(emblem, uri)<br>
etc<br>
<br>
I do believe that this spec would form a necessary basis for such an
API (in the emblem case), or could at least be absorbed by that spec at
a subsequent date</div></div></blockquote><div><br>Yes, this could very well fall under the Wasabi umbrella, but as you say, let&#39;s let that rest for now. <br></div><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div>
I think that standardising on the emblems first, and then an API for
associating them with files is about as far as you can go for
standardising tags/keywords/emblems and stuff. I believe it would be
prohibitively restrictive, performance wise, to require indexers also
keep a (hypothetical) xml file describing the association of all
emblems to files, in addition to their own internal representations of
such relationships [1]</div></div></blockquote><div><br>You are right. An api like you suggest does not enforce a policy on how to actually store the&nbsp; emblem information so any platform could do what it found was the right thing.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div>
[1] Perhaps the answer here is standardising on something like XMP sidecar files and
having indexers periodically write these out to disk. In that case
they would no doubt need to refer back to an emblem which may have been
applied to the associated file.</div></div></blockquote><div><br>As I understand it indexers (atleast Beagle and Tracker)&nbsp; have problems &quot;regarding two files as one&quot;, meaning that they will probably be able to write the sidecar, but not index it so that the metadata is stored for the original file.
<br></div><br>Anyway, let&#39;s postpone the api discussions until the fileformat is set in stone, and Wasabi is firing up on the metadata spec.<br><br>Cheers,<br>Mikkel<br></div>