[XESAM] Extension proposal, alternative search services

[Mikkel Kamstrup Erlandsen]

2007/6/8, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
>
> On Friday 08 June 2007 09:05:19 you wrote:
> > > I just wanna toss this idea out in the wild.
> > >
> > > I want to make it easy to have multiple services expose a xesam search
> > > interface. We would still have the standard desktop search engine with
>
> > > the dbus path and name as specified, but other implementations of the
> > > search interface could be useful too. Consider fx if Gnome's Mugshot
> > > applet ( http://mugshot.org) exposed a xesam search service that could
> > > search in mugshot groups, feeds, and persons. This would not be
> suitable
> > > as an integrated part of the main desktop search service. Another
> example
> > > could be a xesam wrapper for the Yahoo REST api.
> > >
> > > This way we could (at some point in the future) have a small "swarm"
> of
> > > xesam search services (likely with the desktop one as the most
> > > prominent), and applications like deskbar could aggregate these in a a
> > > nice
> > > search-everything-you-can-dream-of-and-then-some applications.
> > >
> > > We can achieve this with almost no changes to the current search
> > > proposal. What we basically need is some way to introspect what
> > > ontologies the search engine is capable of using, and we probably need
> > > that anyway.
> > >
> > > What I actually propose is this: Add a session property
> > > vendor.ontologiesthat has value type aas, an array of ontology
> > > definitions which are triplets [unique_name,version,path]. So fx
> hooking
> > > up to the Yahoo service and calling GetProperty(session, "
> > > vendor.ontologies") returns [["yahoo", "1.0",
> > > "/usr/share/ontologies/yahoo-1.0"]].
> > >
> > > If the main xesam desktop search service had a 3rd party onto
> installed
> > > it might return [["xesam", " 1.0", "/usr/share/ontologies/xesam-1.0],
> > > ["my-app", "0.3.4", "/usr/share/ontologies/my-app-0.3.4]].
> >
> > I was quite in a rush  last night so I forgot half the message of
> course...
> >
> > The values of the ontology-triples [unique_name, version, path] deserve
> > description:
> >  - unique_name: This is a name that uniquely describes the vendor of the
> > ontology.
> >  - version: the version of the ontology
> >  - path: the absolute path to the ontology
> >
> > This leads me with a need to define how ontologies are installed.  I
> would
> > suggest that an ontology is a directory under
> > {XDG_USER_DATA_DIR,XDG_SYSTEM_DATA_DIR}/ontologies named
> > <unique_name>-<version>. All files (in a yet to be specified format) in
> > here are treated as part of the ontology except one designated file (in
> a
> > yet to be specified format) which contain metadata about the ontology.
> This
> > metadata could fx be:
> >  - Vendor name (the unique name as in the dir-name)
> >  - Ontology version
> >  - Full vendor name (free form string)
> >  - Ontology description
> >
> > Anyways, any thoughts? Cheers,
>
> For RDF(S) you don't really need this file. You can embed this info
> anywhere.


Ok, this is just an implementation detail that really depends on what our
final onto representaion is written in , but let's not continue that
discussion right now...

The problem I see here is I'm not sure this is the only change necessary to
> let several xesam indexers work in parallel... I'm no DBUS expert and
> actually hardly know anything, but can several programs run a service with
> the same name?


No.  Alternative search engines must use another bus name than the standard
xesam one. But it is possible to introspect this an retrieve all objects
that implement a given interface (org.feedesktop.xesam.Search).

Also, consider that indexers will likely have plug-ins which extend their
> ontologies, so ontology version may not be as informative, or at least it
> should be clarified that you are describing only the core part of the
> ontology.