[XESAM] New meeting, date+time proposals please

[Evgeny Egorochkin]

On Saturday 19 May 2007 14:37:57 you wrote:
> 2007/5/18, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
> > On Friday 18 May 2007 12:27:30 Mikkel Kamstrup Erlandsen wrote:
> > > > >  * should we allow for multiple inheritance (ie multiple parents
> > > > > for fields)?
> > > >
> > > > I believe there were two issues intermixed: multiple parents for
> >
> > fields
> >
> > > > and
> > > > multiple types or as you say categories for files.
> > >
> > > True. That is two issues, but I got the impression that the
> >
> > Strigi/Nepomuk
> >
> > > camp where in favor of both?
> > >
> > > As I consider multiple inheritance (both cats and/or fields) to be a
> > > somewhat big feature request it needs to be founded on solid reasoning
> >
> > if
> >
> > > we should go with it.
> >
> > I don't consider multiple file types/categories a big feature. Suppose a
> > file
> > has type/category Audio. This means it belongs to the following
> > categories:
> > File, Media, Audio. So it already has multiple types. The question is
> > whether
> > we allow these types to be outside of strict hierarchy.
>
> It all boils down to whether or not we allow cycles in the ontology tree.
> It is a lot easier to parse/update a tree structure if there are no cycles.
> That is why I consider it a big feature.

Cycles? Not sure what you are talking about. We should not allow any type to 
be a parent of itself(indirectly), true, but this is possible even in single 
ineritance case if onto is malformed. Or maybe you should elaborate more?

> 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

> 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).

Actually, the easiest thing would be to claim that DC is the best and 
all-encompassing onto and we don't need anything else since Nepomuk already 
has a DC mapping.

> > Unfortunately we didn't really get to discuss any
> >
> > > practical use cases in the IRC meeting.
> > >
> > > I have not been able to come up with a good use case (of multi inh.)
> > > myself, but maybe some one here can?
> >
> > Source code: It is a text document(contains text) and software(has
> > dependencies on other software).
>
> You mean that it might ref some .h files fx? If that is what you meant I
> can't see why a simple subclass SourceCode->TextFile (or something) isn't
> enough..?

Software has dependencies, maintainer, project it belongs to.

All multiple-inheritance issues can be resolved by moving offending fields 
higher in the hierarchy. This doesn't hurt because they all are optional.
Also, you can eliminate single inheritance and file types as such, without 
much fuss.

The problem with this approach is that software no longer knows which type is 
particular file and consequentially what fields to expect etc.

The advantage of multi- vs single- inheritance is that you describe aspects of 
a file with types, e.g it's a text, software and network resource. Software 
then knows what fields to expect and what it is processing.

If the onto is quite generic, multiple-inheritance may not be needed. I don't 
insist that we must use it. My point is that it's easy to implement and it 
may be useful. Whether/when it will be useful, time will tell.

--Evgeny