2007/5/12, Fabrice Colin &lt;<a href="mailto:fabrice.colin@gmail.com">fabrice.colin@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;">
Hi all,<br><br>On 5/12/07, Joe Shaw &lt;<a href="mailto:joe@joeshaw.org">joe@joeshaw.org</a>&gt; wrote:<br>&gt; I haven&#39;t been following this thread super closely.&nbsp;&nbsp;Why define these<br>&gt; in .desktop-like files rather than in some sort of documented
<br>&gt; specification?&nbsp;&nbsp;Code is what ultimately will be setting these, so it<br>&gt; will have to obey them.<br>&gt;<br>I agree.<br><br>I am not sure I understand the benefit of defining these in some sort<br>of user-editable configuration, instead of in a spec.
<br>If the user defines a new field, it won&#39;t have any effect as the engine has<br>no way to automagically know how that new field maps to the underlying<br>file format. The corresponding metadata extractor will have to be updated
<br>to support the new field and make sure it is retrieved from files.</blockquote><div><br>It was not the idea that an ordinary user should install field definitions. Applications with special needs could do so, but most wouldn&#39;t need to. Do I understand correctly in that you don&#39;t see the need to have the ontology defined in a machine readable way? Just specced out in some document? While this could be done, the machine readable ontology does have quite a few benefits. Fx:
<br><br>&nbsp;* You could update the ontology without updating any applications or search engine code<br><br>&nbsp;* Applications could create dynamic guis that reflects the ontology<br><br>&nbsp;* 3rd parties could extend the ontology by installing their own ones
<br><br><br>Ok let me explain why I personally prefer the .desktop like approach given that we install the ontology on the hard drive in a machine readable way...<br><br>1) It doesn&#39;t introduce dependencies on new 3rd party libs (maybe it does for qt/kde I&#39;m uncertain on their situation). GLib has really good support for .desktop files (with i18n which we need too) in what is known as the keyfile api. A rdf parser is likely to require either a good deal of code in libxesam or a 3rd party lib. 3rd party libs are a big deal we shouldn&#39;t accept with out a great deal of thought.
<br><br>2) Application developers can easily create their own ontologies. Anybody can understand the .desktop approach by looking at one or to field definitions. That is not necessarily the case with rdf.<br><br>3) Although RDF has (relatively) simple representations it might scare developers of by pure reputation.
<br><br></div>4) .desktop is already a de facto standard on the desktop (and xesam is all about the desktop). RDF is a standard, but it&#39;s not greatly used in desktop applications.<br></div><br>5) RDF is extensible to just about any point imagnable, while this is normally good, I think it would be healthy to restrict our selves to some extent, so that we don&#39;t fly of into abstraction space.
<br><br>6) If it turns out eventually that .desktop is too simple, it would be possible to allow rdf ontologies as well. It would not be the most beautiful solution, but I think it is acceptable.<br><br>Cheers,<br>Mikkel<br>