Danny Ayers wrote:
2009/7/28 Kingsley Idehen <[email protected]>:
Please have a look at:
1. http://lod.openlinksw.com - LOD Cloud Cache (5 Billion+ triples from the
LOD Cloud Data Set collection plus others)
2.
http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VirtuosoFacetsWebService
-- Service API
I've also posted comments to his blog post at:
http://www.scripting.com/stories/2009/07/26/twowaySearch.html?dsq=13437902#comment-13437902
Right, I agree this is the key bit of 'Part 2 of the solution'
(looser, Google-like results may also be desirable, but that would be
icing).
Part 1 is a little more than front end though, IMHO. You'd also need to :
* snag the searcher's profile
* generate filter clauses based on that
(in practice the filtering would probably be better the other way
around, i.e. reduce search space using profile facts for triple
matching, then use something like FILTER regex(?object, ?searchterms,
"i") )
Having said that a bit of experimentation is no doubt needed to get a
good interaction between the sloppy text bits and the explicit profile
stuff - e.g. if I searched for "airports" (and my profile contained my
geo location), behind the scenes you'd probably want "airports" to map
to ?s a x:Airport - something your Entity Search tool presumably can
do (alas it keeps timing out for me right now).
Cheers,
Danny.
Danny,
Response to Dave did express #1 is UI atop API. But then I remembered a
wonderful little thing called FOAF+SSL that binds a Person Entity URI to
an X.509 Cert. that is then exported to a Browser and usable across the
Web as a WebID. This very WebID is the conduit to the profile of the
person who is issuing the query. So yet again, we have a real world
problem and the dexterity of HTTP URIs to the rescue :-)
--
Regards,
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software Web: http://www.openlinksw.com
