[XESAM] Ontology snapshot

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Wed Jun 6 12:01:47 PDT 2007

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

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

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.

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

More information about the xdg mailing list