[XESAM] Ontology snapshot

[Mikkel Kamstrup Erlandsen]

2007/6/6, jamie <jamiemcc at blueyonder.co.uk>:
>
> 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


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.


For practical reasons I prefer it as flat as possible


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.

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.


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.


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


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.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070606/574fe1c1/attachment.htm