<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>

<title>In Response to: This is Not the Future (Update #3) </title><link>http://www.openlinksw.com/blog/kidehen@openlinksw.com/blog/?id=1518</link><description>As I cannot post directly to Glenn&#39;s blog titled: This is Not the Near Future (Either), I have to basically respond to him here, in blog post form :-(

What is our &amp;quot;Search&amp;quot; and &amp;quot;Find&amp;quot; demonstration about?
It is about how you use the &amp;quot;Description&amp;quot; of &amp;quot;Things&amp;quot; to unambiguously locate things in a database at Web Scale.

To our perpetual chagrin, we are trying to demonstrate an engine -- not UI prowess -- but the immediate response is to jump to the UI aesthetics.

Google, Yahoo etc.. offer a simple input form for full text search patterns, they have a processing window for completing full text searches across Web Content indexed on their servers. Once the search patterns are processed, you get a page ranked result set (collection of Web pages basically that claim/state: we found N pages out of a document corpus of about M indexed pages).  


Note: the estimate aspect of traditional search results in like &amp;quot;advertising small print&amp;quot; the user lives with the illusion that all possible documents on the Web (or even Internet) have been searched whereas in reality: 25% of the possible total is a major stretch; since the Web and Internet are fractal networks and scale-free, inherently growing at exponential rates &amp;quot;ad infinitum&amp;quot; across boundless dimensions of human comprehension.

The power of Linked Data ultimately comes down to the fact that the user constructs the path to what they seek via the properties of the &amp;quot;Things&amp;quot; in question. The routes are not hardwired since URI de-referencing (follow your nose pattern) is available to Linked Data aware query engines and crawlers.


We are simply trying to demonstrate how you can combine the best of full text search with the best of structured querying while reusing familiar interaction patterns from Google/Yahoo. Thus, you start with full text search, find get all the entities associated with the pattern, then use the entity types or entity properties to find what you seek.

You state in your post:

&amp;quot;To state the obvious caveat, the claim OpenLink is making about this demo is not that it delivers better search-term relevance, therefore the ranking of searching results is not the main criteria on which it is intended to be assessed.&amp;quot; 


Correct.



&amp;quot;On the other hand, one of the things they are bragging about is that their server will automatically cut off long-running queries. So how do you like your first page of results?&amp;quot;. 



Not exactly correct. We are performing aggregates using a configurable interactive time factor. Example: tell me how many entities of type: Person, with interest: Semantic Web, exist in this database within 2 seconds. Also understand that you could retry the same query and get different numbers within the same interactive time factor. It isn&#39;t your basic &amp;quot;query cut-off&amp;quot;.



&amp;quot;And on the other other hand, the big claim OpenLink is making about this demo is that the aggregate experience of using it is better than the aggregate experience of using &amp;quot;traditional&amp;quot; search. So go ahead, use it. If you can.&amp;quot; 
Yes, &amp;quot;Microsoft&amp;quot; was a poor example for sure, the example could have been pattern: &amp;quot;glenn mcdonald&amp;quot;, which should demonstrate the fundamental utility of what we are trying to demonstrate i.e., entity disambiguation courtesy of entity properties and/or entity type filtering.


Compare Googles results for: Glenn McDonald with those from our demo (which dissambiguate &amp;quot;Glenn McDonald&amp;quot; via associated properties and/or types), assuming we both agree that your Web Site or Blog Home isn&#39;t the center of your entity graph or personal data space (i.e., data about you); so getting your home page at the top of the Google page rank offers limited value, in reality.


What are we bragging about? A little more than what you attempt to explain. Yes, we are showing that we can find stuff within a processing window, but understand the following:


Processing Time Window (or interactive time) is configurable


Data Corpus is a Billion+ Triples (from Billion Triples Challenge Data Set)


SPARQL doesn&#39;t have Aggregation capabilities by default (we have implemented SPARQL-BI to deliver aggregates for analytics against large data sets, we even handle the TPC-H industry standard benchmark with SPARQL-BI)

Paging isn&#39;t possible without aggregates, and doing aggregates on a Billion+ triples as part of a query processing cycle isn&#39;t trivial stuff (otherwise it would be everywhere due to inherent and obvious necessity).


I hope I&#39;ve clarified what&#39;s going on with our demo? If not, pose your challenge via examples and I will respond with solutions or simply cry out loud: &amp;quot;no mas!&amp;quot;. 


As for your &amp;quot;Mac OX X Leopard&amp;quot; comments, I can only say this: I emphasized that this is a demo, the data is pretty old, and the input data has issues (i.e. some of the input data is bad as your example shows). The purpose of this demo is not about the text per se., it&#39;s about the size of the data corpus and faceted querying. We are going to have the entire LOD Cloud loaded into the real thing, and in addition to that our Sponger Middleware will be enabled, and then you can take issue with data quality as per your reference to &amp;quot;Cyndi Lauper&amp;quot; (btw - it takes one property filter to find information about her quickly using &amp;quot;dbpprop:name&amp;quot; after filtering for properties with text values). 

Of all things, this demo had nothing to do with UI and Information presentation aesthetics. It was all about combining full text search and structured queries (sparql behind the scenes) against a huge data corpus en route to solving challenges associated with faceted browsing over large data sets. We have built a service that resides inside Virtuoso. The Service is naturally of the &amp;quot;Web Service&amp;quot; variety and can be used from any consumer / client environment that speaks HTTP (directly or indirectly).

To be continued ...
</description><pubDate>Tue, 13 Jan 2009 04:18:12 GMT</pubDate><generator>Virtuoso Universal Server 08.03.3334</generator><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Kingsley Uyi Idehen</dc:creator><image><title>In Response to: This is Not the Future (Update #3) </title><url>http://www.openlinksw.com/weblog/public/images/vbloglogo.gif</url><link>http://www.openlinksw.com/blog/kidehen@openlinksw.com/blog/?id=1518</link><description>I have seen the future and it&#39;s full of Linked Data! :-)</description><width>88</width><height>31</height></image>
<item><title>Kingsley Uyi Idehen</title><guid>http://www.openlinksw.com/blog/kidehen@openlinksw.com/blog/?id=1518#4639</guid><link>http://www.openlinksw.com/blog/kidehen@openlinksw.com/blog/?id=1518#4639</link><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">kidehen@openlinksw.com</dc:creator><pubDate>Tue, 13 Jan 2009 19:32:48 GMT</pubDate><description>&lt;br /&gt;
glenn mcdonald wrote: &lt;br&gt;&amp;lt;&amp;lt;&amp;lt;&lt;br&gt;  I&#39;m not complaining about &quot;aesthetics&quot;, nor even exactly about UI. You&#39;re trying to make the case that this new technology (both semantic web technology in general, and Virtuoso&#39;s in particular) can provide a better searching/finding experience. (Which is something I also believe.) But the experience of using this demo is bad. You say its drawbacks are irrelevant to what you&#39;re trying to show. But the irrelevance is in the way, and I think the problems with this demo swamp out the technical virtues. And since&amp;nbsp;bad demos kind of diminish everything by association, I think you reinforce the prevalent impression that &quot;this stuff&quot; is esoteric gibberish.&lt;div&gt;&lt;br&gt;&lt;/div&gt;&lt;div&gt;So my challenge? Do a demo that picks some coherent, explainable thing, and is clearly and unambiguously good at &lt;i&gt;that&lt;/i&gt;, without&amp;nbsp;requiring caveats and partial apologies.&lt;br&gt;&amp;gt;&amp;gt;&lt;br&gt;&lt;br&gt;Glenn,&lt;br&gt;&lt;br&gt;The reason for the disclaimer is because on the &quot;Web&quot; I can make a web page on viewable by a user agent of type: Programmer, for instance. This demo was all about Entity-Attribute-Value (of Subject-Predicate-Object) based navigation of entity graphs when the corpus is large with the scale-free realities of the Web in play.&amp;nbsp; &lt;br&gt;&lt;br&gt;The goal was to show a Web Service that can alleviate higher level developers of the grunt work associated with the low-level DBMS engine stuff.&lt;br&gt;&lt;br&gt;That said, I also agree with&amp;nbsp; &quot;esoteric&quot; concern perspective that bare-bones UI demos inadvertently perpetuate :-) Thus, we will continue to improve the basic UI of this service, and get more supporting collateral out the door.&lt;br&gt;&lt;br&gt;Thus, do we have a deal? Also, I am all ears re. any UI enhancements you would like to see.&lt;br&gt;&lt;br&gt;Happy New Year!&lt;br&gt;&lt;br&gt;Kingsley&lt;br&gt;&lt;/div&gt;&lt;br&gt;    
</description></item><item><title>glenn mcdonald</title><guid>http://www.openlinksw.com/blog/kidehen@openlinksw.com/blog/?id=1518#4638</guid><link>http://www.openlinksw.com/blog/kidehen@openlinksw.com/blog/?id=1518#4638</link><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">gmcdonald@furia.com</dc:creator><pubDate>Tue, 13 Jan 2009 18:25:17 GMT</pubDate><description>&lt;br /&gt;
I&#39;m not complaining about &quot;aesthetics&quot;, nor even exactly about UI. You&#39;re trying to make the case that this new technology (both semantic web technology in general, and Virtuoso&#39;s in particular) can provide a better searching/finding experience. (Which is something I also believe.) But the experience of using this demo is bad. You say its drawbacks are irrelevant to what you&#39;re trying to show. But the irrelevance is in the way, and I think the problems with this demo swamp out the technical virtues. And since&amp;nbsp;bad demos kind of diminish everything by association, I think you reinforce the prevalent impression that &quot;this stuff&quot; is esoteric gibberish.&lt;div&gt;&lt;br&gt;&lt;/div&gt;&lt;div&gt;So my challenge? Do a demo that picks some coherent, explainable thing, and is clearly and unambiguously good at &lt;i&gt;that&lt;/i&gt;, without&amp;nbsp;requiring caveats and partial apologies.&lt;/div&gt;&lt;br /&gt;

</description></item><item><title>Re: In Response to: This is Not the Future</title><guid>http://www.openlinksw.com/blog/kidehen@openlinksw.com/blog/?id=1518#4637</guid><link>http://www.openlinksw.com/blog/kidehen@openlinksw.com/blog/?id=1518#4637</link><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Kingsley Uyi Idehen (kidehen@openlinksw.com)</dc:creator><pubDate>Tue, 13 Jan 2009 12:20:51 GMT</pubDate><description>Matthias,

Thanks for your comments. The ideal solution comes down to combining the best of Document oriented full text search and structured Linked Data queries (driven by entity types and property filtering). 

Virtuoso possesses an in-built full text search engine, and we can tweak both the demo core and its UI to also unveil this aspect of Virtuoso in more depth via a page rank demo. Of course, we can also play well with Google and Yahoo (via job delegation). The only issue right now is time, we never set out to demonstrate page rank, this demo is all about structured querying :-)


Kingsley  </description></item><item><title>Matthias Samwald</title><guid>http://www.openlinksw.com/blog/kidehen@openlinksw.com/blog/?id=1518#4635</guid><link>http://www.openlinksw.com/blog/kidehen@openlinksw.com/blog/?id=1518#4635</link><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">samwald@gmx.at</dc:creator><pubDate>Tue, 13 Jan 2009 09:48:09 GMT</pubDate><description>The comments about the user interface in this blog are indeed quite improper.&lt;br&gt;However, the point being made about the importance of ranking based on relevance is very important, and has indeed not been properly addressed in Semantic Web / LOD developments so far.&lt;br&gt;&lt;br /&gt;

</description></item>
</channel>
</rss>
