2007/5/12, Fabrice Colin <<a href="mailto:fabrice.colin@gmail.com">fabrice.colin@gmail.com</a>>:<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 <<a href="mailto:joe@joeshaw.org">joe@joeshaw.org</a>> wrote:<br>> I haven't been following this thread super closely. Why define these<br>> in .desktop-like files rather than in some sort of documented
<br>> specification? Code is what ultimately will be setting these, so it<br>> will have to obey them.<br>><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'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't need to. Do I understand correctly in that you don'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> * You could update the ontology without updating any applications or search engine code<br><br> * Applications could create dynamic guis that reflects the ontology<br><br> * 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't introduce dependencies on new 3rd party libs (maybe it does for qt/kde I'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'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'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'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>