No subject
Fri Jun 8 07:20:02 PDT 2007
extend the xesam onto or they are completely orthogonal, that is they are
not part of the xesam ontology. I don't think we should put them in the same
dir as the files describing the xesam onto.
Another point: many ontologies can co-exist with the aid of namespacing. You
> can lump together results from queries to any number of indexers, and
> it'll
> work just fine.
Yeah, I know. Putting the ontos in different dirs was not meant as a way to
do pseudo namespacing. We should use real namesping for this. Having the
ontos in different dirs was just to make it easier for apps needing to parse
the different ontos.
Cheers,
Mikkel
-- Evgeny
>
------=_Part_63195_2885201.1181314402707
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
2007/6/8, Evgeny Egorochkin <<a href="mailto:phreedom.stdin at gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">phreedom.stdin at gmail.com</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Friday 08 June 2007 09:05:19 you wrote:<br>> > I just wanna toss this idea out in the wild.<br>> ><br>> > I want to make it easy to have multiple services expose a xesam search<br>> > interface. We would still have the standard desktop search engine with
<br>> > the dbus path and name as specified, but other implementations of the<br>> > search interface could be useful too. Consider fx if Gnome's Mugshot<br>> > 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<br>> > search in mugshot groups, feeds, and persons. This would not be suitable<br>> > as an integrated part of the main desktop search service. Another example
<br>> > could be a xesam wrapper for the Yahoo REST api.<br>> ><br>> > This way we could (at some point in the future) have a small "swarm" of<br>> > xesam search services (likely with the desktop one as the most
<br>> > prominent), and applications like deskbar could aggregate these in a a<br>> > nice<br>> > search-everything-you-can-dream-of-and-then-some applications.<br>> ><br>> > We can achieve this with almost no changes to the current search
<br>> > proposal. What we basically need is some way to introspect what<br>> > ontologies the search engine is capable of using, and we probably need<br>> > that anyway.<br>> ><br>> > What I actually propose is this: Add a session property
<br>> > vendor.ontologiesthat has value type aas, an array of ontology<br>> > definitions which are triplets [unique_name,version,path]. So fx hooking<br>> > up to the Yahoo service and calling GetProperty(session, "
<br>> > vendor.ontologies") returns [["yahoo", "1.0",<br>> > "/usr/share/ontologies/yahoo-1.0"]].<br>> ><br>> > If the main xesam desktop search service had a 3rd party onto installed
<br>> > it might return [["xesam", " 1.0", "/usr/share/ontologies/xesam-1.0],<br>> > ["my-app", "0.3.4", "/usr/share/ontologies/my-app-0.3.4]].<br>><br>> I was quite in a rush last night so I forgot half the message of course...
<br>><br>> The values of the ontology-triples [unique_name, version, path] deserve<br>> description:<br>> - unique_name: This is a name that uniquely describes the vendor of the<br>> ontology.<br>> - version: the version of the ontology
<br>> - path: the absolute path to the ontology<br>><br>> This leads me with a need to define how ontologies are installed. I would<br>> suggest that an ontology is a directory under<br>> {XDG_USER_DATA_DIR,XDG_SYSTEM_DATA_DIR}/ontologies named
<br>> <unique_name>-<version>. All files (in a yet to be specified format) in<br>> here are treated as part of the ontology except one designated file (in a<br>> yet to be specified format) which contain metadata about the ontology. This
<br>> metadata could fx be:<br>> - Vendor name (the unique name as in the dir-name)<br>> - Ontology version<br>> - Full vendor name (free form string)<br>> - Ontology description<br>><br>> Anyways, any thoughts? Cheers,
<br><br>For RDF(S) you don't really need this file. You can embed this info anywhere.</blockquote><div><br>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...
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The problem I see here is I'm not sure this is the only change necessary to
<br>let several xesam indexers work in parallel... I'm no DBUS expert and<br>actually hardly know anything, but can several programs run a service with<br>the same name?</blockquote><div><br>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).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, consider that indexers will likely have plug-ins which extend their
<br>ontologies, so ontology version may not be as informative, or at least it<br>should be clarified that you are describing only the core part of the<br>ontology.</blockquote><div><br>From my POW 3rd party ontologies are "new" ontologies regardless if they extend the xesam onto or they are completely orthogonal, that is they are not part of the xesam ontology.
I don't think we should put them in the same dir as the files describing the xesam onto.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Another point: many ontologies can co-exist with the aid of namespacing. You<br>
can lump together results from queries to any number of indexers, and it'll<br>work just fine.</blockquote><div><br>Yeah, I know. Putting the ontos in different dirs was not meant as a way to do pseudo namespacing. We should use real namesping for this. Having the ontos in different dirs was just to make it easier for apps needing to parse the different ontos.
<br><br>Cheers,<br>Mikkel<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-- Evgeny<br></blockquote></div><br>
------=_Part_63195_2885201.1181314402707--
More information about the xdg
mailing list