[XESAM] New meeting, date+time proposals please

[Evgeny Egorochkin]

On Monday 21 May 2007 12:42:25 Sebastian Trüg wrote:
> > > > Multiple field inheritance, is too in my opinion is not a big feature
> > > >
> > > > > > request
> > > > > > if inheritance is implemented as such. It might be useful if we
> > > > > > link multiple
> > > > > > external ontologies. If we stick with a relatively simple core
> > > >
> > > > ontology,
> > > >
> > > > > > it
> > > > > > may not be required. Time will tell.
> > > > >
> > > > > "We" in this context is *only* the nepomuk project mind you
> > > > > (correct me
> > > >
> > > > if
> > > >
> > > > > I'm wrong please). There are no plans what so ever for integrating
> > > > > with general ontologies in xesam. You can extend the xesam ontology
> > > > > with
> > > >
> > > > other
> > > >
> > > > > xesam-compliant ontologies and that's it.
> > > >
> > > > Sorry? I was under impression that Tracker and Beagle wanted to reuse
> > > > existing
> > > > ontologies as much as possible? So I proposed to make a core
> > > > xesam-specific
> > > > ontology with mappings to DC, EXIF etc, since it's impossible to
> > > > cleanly link
> > >
> > > I think we agree here :-) I might have been unclear. What I meant is
> > > that xesam should not necessarily be interoperable with any old
> > > ontology off the web. Priority ones like EXIF and such is another case
> > > that I do think we should expose/consume/embed/extend (/me don't
> > > consider DC an ontology). We should be interoperable with
> > > desktop-related widespread standards IMHO, but these should be nailed
> > > down before hand.
> > >
> > > > Xesam should of course not restrict Nepomuk from doing this.
> > > >
> > > > You're under wrong impression that I'm lobbying nepomuk-specific
> > > > features to
> > > > make life for nepomuk easier. In fact, the simpler is xesam onto(no
> > > > matter how badly screwed it is), the easier it will be for nepomuk to
> > > > map it. The reason is that the only mapping needed is Nepomuk->Xesam
> > > > and not vice versa.
> > > > So Nepomuk doesn't have to decipher and work around any Xesam onto
> > > > simplifications/deficiencies(as compared to Nepomuk).
> > >
> > > Oh, I was not aware of what the Nepomuk needs actually where, but if
> > > they only need a map Nep->Xes then our life is easier :-)
> >
> > I can't really speak for nepomuk, this is my personal POV.
>
> What I think is needed is a mapping that allows nepomuk to reuse xesam
> data. Thus, we need a mapping from the xesam onto to the nepomuk ones, i.e.
> all xesam fields should be mapped to a specific nepomuk field. This allows
> some freedom regarding xesam but the closer the xesam onto is to the
> nepomuk style (inheritance and types and stuff) the easier is the mapping
> and the more data can be reused. Even more so, if the mapping would work
> both ways (at least partially) xesam-aware apps could benefit from
> nepomuk-only data and thus, get better search results.

Nepomuk->Xesam mapping is possible since xesam onto is going to be an order of 
magnitude simpler than nepomuk one.

Xesam->Nepomuk would not be a trivial task I'm afraid. Of course it would be 
nice to use Xesam as one of data sources for Nepomuk, but it will be at best 
incomplete and at worst ambiguous.

There are other reasons why I think multiple-inheritance, types/categories and 
category-field links are a must:

*** won't complicate matters(implementation-wise) even for the simplest ones

*** improve ontology readability/comprehensibility for humans

*** provide additional clues to software on how to deal with particular files 
or fields. 

This is especially useful when dealing with custom extensions. Apps can know 
how to deal with standard xesam onto, but *the only description/documentation 
of custom extensions by other apps is the onto itself*.

*** Improve extension isolation to avoid interference between many installed 
extensions and help maintain ontology structure. e.g. file property/metadata 
editors will greatly benefit if the ontology has a structure by understanding 
what categories a particular file belongs to, what fields apply etc.

*** we won't have to change spec or resort to ugly workarounds if we ever hit 
artifically-imposed limitations like single-inheritance. We can make 
decisions for xesam-specific issues, but we can't know for sure what 
functionality a particular xesam-aware app will want to implement and whether 
devs will appreciate the simplification. 

*** allow indexers to expose additional functionality ranging from simple 
annotation to complex metadata structures.

*** a well-researched solution with predictable benefits/drawbacks.

--Evgeny