Here are the minutes of our meeting yesterday (2007-05-15). Sorry it is a bit short, but my time is limited... ATTENDING: Gunnar (nepomuk), Sebastian (nepomuk), Jamie (tracker), Jos (strigi), Evgeny (strigi), Mikkel (vigilante ninja) AGENDA: <pre> * libxesam, libxesam-{glib,qt} - should we provide helper libs, other than the ones native ones of the backends? - what are the needs? - platform bindings (qobject,gobject) * RDF vs .desktop - Do we have a profound conflict of interests? - can we create a cludge solution? * Types/categories/services, how do they fit in? - should the type system be orthognal or dependent on the field definitions - is a kludge possible here? </pre> MEETING:  * It was proposed that we had a platform independent libxesam with the core non-dbus related utilities such as query parsing and query construction. It was the general consensus that the time wasn't right. It might be good to have one, but we should wait and reconsider this when the spec was set was more mature. Toolkit specific libs abstracting away dbus and other evils should be provided at some point though.  * Mikkel suggested that perhaps the spirits of Nepomuk and more KIS-type services where simply incompatible when it comes to the requirements of the ontologies, and we might have to come up with some kludge solution where noth rdf and .desktop ontos could be used. This was quickly rejected by most parties though, one representation for the ontology was high priority.  * A simple rdf syntax for the ontology like n3/turtle was proposed, given a bit of thought these could be made almost as simple as .desktop files. Jamie pointed out that a new file format might give problems for translators. Jos and Sebastian argued that KDE had a system where translations of of new file types isn't a problem, and that we could use the same scripts for the Gnome camp.  * It was decided that Evgeny should do some illustrative examples of 4-5 field definitions in both rdf/n3 and .desktop and that we should take these to the relevant parts of our developer communities for comments (maybe also ask some translators).  * We reopened the services/types/categories debate, and quickly settled on the name categories to avoid confusing the word "type" from field types. Example categories are Video, Audio, Email, Contacts, etc.  * It was brought up again whether this category system should be independent or dependent on the field definitions. Again we where split in two camps. Strigi/Nepomuk arguing that the fields should be able to only be defined on certain cats, and Mikkel/jamie on the other side arguing for simplicity of the spec.  * Somehow it cropped up whether or not fields and categories should be able to have multiple parents. Again two camps: Nepomuk/Strigi saying "yes we want multiple inheritance" and Jamie/Mikkel saying "no KIS". Cheers Mikkel