2007/5/17, Fabrice Colin <<a href="mailto:fabrice.colin@gmail.com">fabrice.colin@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;"> On 5/16/07, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> wrote: > 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. > Agreed. I don't see this as a must-have. >  * 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. > Did you guys come up with a full list ?</blockquote> <div> Nope, not yet. We still need to agree on how the "list" should be structured. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> >  * 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. > I think it should be dependent on the field definitions. For instance, it doesn't make sense to set Audio.Composer on something that's been categorized as Email.</blockquote><div> That is totally correct, but does this have to be reflected in the ontology? Why not just have this in a written spec, or just implied by common sense?  </div>Each new feature/requirement we add to the spec makes it harder to implement and harder to understand. Cheers, Mikkel </div>