2007/6/7, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 ( <a href="http://mugshot.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://mugshot.org</a>) 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.ontologies that 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]].</blockquote><div> 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, Mikkel </div></div>