W3C home > Mailing lists > Public > public-lod@w3.org > May 2009

Re: Yet Another LOD cloud browser

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 15 May 2009 21:32:05 -0400
Message-ID: <4A0E1795.6040509@openlinksw.com>
To: Sandro Hawke <sandro@w3.org>
CC: Hugh Glaser <hg@ecs.soton.ac.uk>, Sherman Monroe <sdmonroe@gmail.com>, "semantic-web@w3.org" <semantic-web@w3.org>, Linked Data community <public-lod@w3.org>, David Huynh <dfhuynh@alum.mit.edu>
Sandro Hawke wrote:
>> Sure; I just disagree that a browser that essentially gives a view of
>> one linked data portal should be promoted as a "linked data browser".
>> By that definition something like http://revyu.com/ is a linked data
>> browser.
>>
>> Long ago in what used to be called the Semantic Web world, it was
>> thought that collecting rdf from out there and loading it into a
>> single store and then writing applications over it (such as CS
>> AKTiveSpace) constituted a Semantic Web application.
>>
>> But then some time later, but also long ago, we realised that it was
>> only an application using semantic web technologies, as there was no
>> web involved.  I think we are in danger of repeating this
>> misconception and distraction again in the Linked Data world.
>>
>> Fundamentally the data that your browser works over is a single Linked
>> Data site. This site may have data that has been gathered from lots of
>> places, and URIs that reflect those places somehow in the text, but in
>> the end it is a single site.
>>
>> I don't think I can give your browser any URI I choose that resolves
>> using http to a typical LD document?  If not, it is not a linked data
>> browser.
>>
>> I used to have a mantra: "Putting the Web into Semantic Web".  It now
>> seems I need to say "Putting the Web back into Linked Data", or even
>> "Putting the Web into the Web of Data".
>>
>> It may be we will just have to differ on this; however I would be really
>> interested to know if I am alone in my view -- any comments from others?
>>     
>
> I'm with you 100% here.   
>
> Tabulator is an example of a "real" client-side semantic web browser.
> At one point I had working server-side code that was similar; like
> Kingsley's machine, it had a large database of site's data it had been
> loaded with, BUT if you ever used a URI it hadn't already tried, it put
> that URI on the high-priority harvesting queue, and (when things worked
> well) had slurped in the data before you got your response -- so it
> appeared to have all the LOD data in it.  SPARQL servers can do that
>   

Sandro,
> too, and I imagine some do.
>   
To clarify re. stuff related to Virtuoso re. Linked Data.

1. OpenLink Data Explorer (ODE) -- This is a Tabulator equivalent re. 
core functionality as Linked Data browsers (both re. Browser Extension 
option and Server hosted options) that uses the Sponger (Zitgist also 
uses the Sponger)
2. Sponger -- The URI dereferencing engine (support HTTP URIs and other 
schemes such as Handle System based lsid and doi) also exposed via a 
REST API
3. Faceted Browser Engine -- server hosted and exposed via REST API
4. Web Content Crawler -- server hosted with hooks into the Sponger and 
Virtuoso task scheduler
5. Virtuoso -- SPARQL compliant Quad Store and host of all of the above

Sherman has currently only put item 3 to use from his Virtuoso based 
service.
> The interesting questions is can we have stateless SPARQL servers that
> distribute the query to other SPARQL servers, and what metadata do they
> need to do that well?  
> I guess voiD is supposed to address that; I don't
> know how well it does it, etc.  (I haven't had a chance to follow this
> work much recently.)
>   
Yes, VoiD graphs cover that. The thing we need to do is standardize the 
auto-discovery patterns so that smart federated SPARQL is feasible :-)

Example of a VoiD graph: http://lod.openlinksw.com/void/Dataset .

Kingsley
>      -- Sandro
>
>
>   


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com
Received on Saturday, 16 May 2009 01:32:44 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:20 UTC