David Huynh wrote:
Sherman Monroe wrote:
Kingsley wrote:
There are half a dozen Entities across N graphs in the Quad Store.
The UI issue here is that we don't show the source Graphs in the
results page. Reason, we know we can actually provide distinct
results cheaper than listing the Graph Names etc..
Your timing is borderline impeccable, we will actually be
releasing the Distinct optimization that showcases what I mean.
Anyway, for now, when you select one of the Microsofts from
DBpedia graphs, click on the "Stats" link, it will give you a back
door view of where the data has come from.
David, also keep in mind that this is one of the benefits of
set-based browsing. If I have a results set of twenty synonymous URIs
representing Microsoft, for someone researching Microsoft, such a
list would be a goldmine, because I can click razorbase ->
Information and view all information for all 20 versions of that one
entity simultaneously. In fact, when I get sparse results for an
entity, I always click the razorbase -> Information -> "Alternative
Identities" (e.g. owl:sameAs) and also I look under the reverse
properties for the same, to pull any alias that I may not be away of.
Hi Sherman,
I guess I'm just trying to close the gap between Google's search
results--which people are familiar with--and razorbase's or any novel
search engine's results. For example, when I search for Microsoft on
Google, the first result not only IS what I want, but also LOOKs like
what I want. I can make the decision to click on it within maybe 1 or
2 seconds.
But what happens when you want an entity associated with pattern:
Microsoft that isn't the highly referenced company: Microsoft, in
google's document index?
The view we have is this:
1. Hook into Google and Yahoo and MSFT for pages and even apply a
weighting or our algorithm so that Google|Yahoo|MSFT first page will be
the same as ours (* this is deliberately not part of the LOD instance
since sponging is disabled for now*)
2. Extend this somewhat popularity skewed algorithm with the ability to
disambiguate using Entity Type ( Category re. Sherman's UI) and
Properties (Information re. Sherman's UI).
The URL "www.microsoft.com" in that search result is perhaps the most
convincing element, as I know only *the* Microsoft can possibly own
that domain. (This will be a challenge for any SW search engine,
because no-one can own any URI, and so, seeing a URI alone means
pretty much nothing.
URI means: here is the Identifier for an Data Object in this Data Space.
It means that a simple click will unravel its essence in a
representation overtly or covertly negotiated between user agent and
data server.
That's one of the main differences between URL and URI, which is
usually swept under the rug.)
I hope I've taken it out from under the rug. A URL is a URI :-)
I believe that these "little details" play a big role in how users
interact with SW search engines. It's not just that the search engine
should return the right result, but that it should convince the user
that the right result is right.
Sure, and hopefully, we will collectively make all of these things
clearer :-)
Kingsley
As always, enjoy chatting with you :-)
Indeed, the LOD owes a lot to your work!!
Glad to have helped! :)
David
--
Regards,
Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software Web: http://www.openlinksw.com
