2007/5/24, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Minutes of meeting, 2007-05-23 <MINUTES> Attending: Jos, Jamie, Joe, Evgeny, Sebastian, Mikkel (and later Antoni Mylka (of DFKI)) Note: We decided to call .desktop .ini instead since .desktop is really wrong in this context. I shall use .ini in this recap.  - We started out talking about zesam in general terms - what the project was really about.  Kamstrup thinks that xesam is about providing a simple interface for dedsktop search and metadata that can be implemented in many places and forms. He would also like to adhere as much as possible to the KIS principle, especially in this first iteration.   Not many objections to this. It was pointed out that xesam should never try and be as general as Nepomuk. This was also really far from being the case.   Sebastian aired that xesam potentially could be a part of nepomuk.    - Kamstrup suggests a hearing round where everybody can express their points regarding the metadata spec. Jamie: Is pro a .ini-approach because:  1) they are in wide use  2) toolkits can use them  3) translators can use them  4) its the least amount of work  5) its easy for third party apps to ship metadata .ini files Joe: Don't really care how the serialization format of the ontology turns out. Beagle will not be using it near-term anyway. He stresses that it is mostly the field conventions that are used by actual metadata extraction programs.   He is not keen on the idea of apps dynamically create UIs from the ontology. You need to present the metadata in a way that suits the context, not just a list of fields.   Kamstrup: Wants to keep everything as simple as possible in the first take until we are sure what out needs are. Also he want the spec in  entirety to be grokkable by most without a search/metadata background at a glance. He prefers the .ini approach. Evgeny: Also want to keep it simple for devs. He believes that Turtle is as easy to understand as .ini - atleast if we restrict our selves to the subset of Turtle that we need (not allowing full lown Turtle). Also a Turtle based ontology can be viewed and edited with visual tools. If we impose any new conventions in the .ini format it will be as hard to parse as Turtle. Sebastian: In addition to Evgenys points he will like to point out that Turtle is a well known standard for ontologies. Also other tools can use the xesam ontology if it uses Turtle and we can adopt 3rd party ontologies as well. Jos: Thinks that we should concentrate work on:  - focus on the fields we allow search in, file types/categories are a bonus  - focus on what we define for the fields  - agree on default shortcuts for the fields  - agree on the data types we use in the fields ( preferrably closely linked to XML Schema types)  - describe units (meters, amperes, Hz) and define a default unit per field  - work on a test set to check conformance to the spec  - should make the distinction between embedded and not embedded  - focus on fields for now because it's less work Considering the format he thinks .ini is ugly but simple, and that we use it in the wrong way - group headers should have well defined names, not just arbitrary field names. He would like an RDF representation, but it need not be the only representation. Also there are tools to check the validity of an RDF ontology. Kamstrup and Jamie chimes in and claim that it is indeed legal to use arbitrary group headers in .ini. Fx, like in the icon-naming-spec. Joe would like to know how i18n works in Turtle.Evgeny has an example here <a href="http://lists.freedesktop.org/archives/xdg/2007-May/008252.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.freedesktop.org/archives/xdg/2007-May/008252.html</a>. He points out that the translation infrastructure (in Gnome) is already ready for .ini and xml files. The complexity of implementing a Turtle parser in C is discussed. It seems unclear what the requirements for such a parser would be in our case where we don't need full Turtle. We haven't decided on a Turtle subset yet, so... It is proposed that we use both .ini and rdf/Turtle. This is quickly shot down since we need 3rd party extensibility and apps need to be able to parse the ontology if they wish. Antoni Mylka (of DFKI) points to the Raptor Turtle parser. A C library licensed under Apache2 and LGPL-2.1 (choose one). Mikkel suggests that Tracker could use libraptor as a start out (or some inlined pieces) and move to a real glib based one at a later point if Raptor is to big a dependency. Jamie will accept Turtle if Gnome developers and translators will accept it. Kamstrup promises to go out and get some opinions. Mylka advertises <a href="http://www.dfki.uni-kl.de/%7Emylka" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.dfki.uni-kl.de/~mylka </a> on xesam vs nepomuk. Mikkel tries to get some opinions on <a href="http://wiki.freedesktop.org/wiki/XesamSearchUpdates" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://wiki.freedesktop.org/wiki/XesamSearchUpdates</a>. Jos acknowledges all changes except part 5 about dbus objects instead of plain handles. Since Fabrice said the same in a private mail to Mikkel, they will be merged. </MINUTES> IRC log available from <a href="http://wiki.freedesktop.org/wiki/XesamMetadataFieldsDraft" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://wiki.freedesktop.org/wiki/XesamMetadataFieldsDraft </a></blockquote><div> The search spec has been updated as described by <a href="http://wiki.freedesktop.org/wiki/XesamSearchUpdates">http://wiki.freedesktop.org/wiki/XesamSearchUpdates</a>, except pount 5 about native dbus objects. </div> </div>Cheers, Mikkel