2007/5/17, 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 Thursday 17 May 2007 14:22:50 Fabrice Colin 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. Indeed not all fields apply to all files/categories. Those that apply to every file should be linked to a generic File category. Hardly audio.composer applies to a text document, and if assigned doesn't really make sense. Such limitations are natural, not artifical. They just expose semantics better. To human, composer as such applies to music, but software can only understand this link if directly specified. For interop with other software, it's better to have explicit field-category links.</blockquote><div> I regard the category<->field linking to be a feature just as any other. And in that respect i t needs to be justified just as any other. Simply "expose semantics better" is not good enough for me, do you have a more concrete example of where it enhances user and developer experience? Cheers, Mikkel </div> </div>