<div>2007/6/6, jamie <<a href="mailto:jamiemcc@blueyonder.co.uk">jamiemcc@blueyonder.co.uk</a>>:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Wed, 2007-06-06 at 16:37 +0200, Mikkel Kamstrup Erlandsen wrote: > I've been bugging about trying to figure out how we can please > everyone with regards to categories and sources. > > There seem to be consensus on the following: Each object has two > designated *single valued* fields Category and Source. These two > fields imply what other fields makes sense on the object (as implied > by the purple arrows in Evgenys diagram). > > Important: There is a trade off made here. We basically have two > choices to avoid a lot of duplication/ambiguities in the onto: Either > we allow multiple inheritance (on categories is all that is needed) or > we have multiple values for the category field. I talked this over > with Evgeny and we ended up with the multiple-inheritance for cats. > The example here could be that a SourceCode cat derives from both > TextDocument and Software. > such a scheme screws up our search results by category in tracker we have search by cat for Development Files and Text Files but we do not show Dev files under Text Files. Having a deep hierarchy will also cause lots of dupes in search results for different cats</blockquote> <div> I don't understand the problem. You can split out the cats by putting it in the Devel cluster if object.cat >=SourceCode and in the Text File cluster if SourceCode > object.cat >= TextDocument this should be a negligible overhead, no? I think MI causes problems (in the sense of dupes between clusters) if you insist on mapping cats to clusters 1:1 where one of the clusters you form map to a cat with multiple parents. If you are willing to do filtering like I describe above then you can wheat this duplication out.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For practical reasons I prefer it as flat as possible</blockquote><div> Here's an example illustrating why I prefer nested cats. Consider a hypothetic app MyCommunicationsCenter (MCC). It shows everything of cat Message in the default view (Emails and IM by default). Now if a 3rd party app install a new kind of Message cat (fx recorded video chats with voice-recognized transcripts as metadata (anyone? :-D)), call it VideoMessage. Now MCC will automatically pick up VideoMessages without any modifications. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Current tracker onto for File based cats is: All Files -> Music -> Documents -> Text -> Videos -> Images -> Development -> Folders As you can see there is no need for more than one level deep inheritance and absolutely no need for MI. Even if you put Dev files under Text, Text still inherits from All Files so a need for MI is not necessary.</blockquote><div> Just because you can create a list without the need for nested cats doesn't prove that they are generally over kill. As I think my MCC example above illustrates.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Text in tracker does not show Docs or Dev files (even if they are text based) as they have their own cat. I really dont like duplicating results in different cats</blockquote><div> This seems like an arbitrary classification of files just to avoid a (small) bit of leg work. Or can you clarify why Text and Documents are unrelated. When is a bog standard README or LICENSE not a document? The user have to employ knowledge that READMEs are generally stored in plain text to conclude that she must find the README in question under Text and not Documents. </div> </div>Cheers, Mikkel