2007/5/18, Evgeny Egorochkin <<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@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 Friday 18 May 2007 09:22:30 Mikkel Kamstrup Erlandsen wrote: > > >  * 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. > > 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? > > Each new feature/requirement we add to the spec makes it harder to > implement and harder to understand. The easiest way to write it in spec is put this info into ontology. This doesn't impose any artifical limitations on the software, so implementations can ignore these limits and hope that data sources will provide sane data just like they do if the limitations are implied but not specified. It makes easier to understand the ontology for both humans and software since this explicitly specifies which fields should be used for a particular file type/category. It is especially important for software, since it doesn't have any other way to deduce this info.</blockquote><div> You are correct. Implementations can ignore this and the world would still stand. Your point about GUIs better being able to display metadata relevant to the object in question (in a dynamic way) is also good. I think this is one of the points where I might reconsider my initial skepticism :-) Cheers, Mikkel </div> </div>