W3C home > Mailing lists > Public > semantic-web@w3.org > March 2010

Re: RelFinder - Version 1.0 released

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 15 Mar 2010 10:30:39 -0400
Message-ID: <4B9E448F.9020403@openlinksw.com>
To: Steffen Lohmann <steffen.lohmann@uni-duisburg-essen.de>
CC: public-lod@w3.org, semantic-web@w3.org, dbpedia-discussion@lists.sourceforge.net, Timo Stegemann <timo.stegemann@uni-due.de>, Philipp Heim <philipp.heim@vis.uni-stuttgart.de>, Virtuoso Users <virtuoso-users@lists.sourceforge.net>
Steffen Lohmann wrote:
> Thanks Kingsley,
> I quickly added URIBurner as a dataset but cannot see the added value 
> w.r.t. the RelFinder - your Google-Apple example produces mainly 
> "seeAlso" links, which are not that helpful to discover new 
> relationships. Here is the link with the parameters:
> http://relfinder.semanticweb.org/RelFinder.swf?obj1=R29vZ2xlfGh0dHA6Ly9kYnBlZGlhLm9yZy9yZXNvdXJjZS9Hb29nbGU=&obj2=QXBwbGV8aHR0cDovL2RicGVkaWEub3JnL3Jlc291cmNlL0FwcGxl&name=VVJJQnVybmVy&abbreviation=YnVybmVy&description=QSBzZXJ2aWNlIHRoYXQgZGVsaXZlcnMgUkRGLWJhc2VkIHN0cnVjdHVyZWQgZGVzY3JpcHRpb25zIG9mIFdlYiBhZGRyZXNzYWJsZSByZXNvdXJjZXMgKGRvY3VtZW50cyBvciByZWFsIHdvcmxkIG9iamVjdHMpIGluIGEgdmFyaWV0eSBvZiBmb3JtYXRzIHRocm91Z2ggR2VuZXJpYyBIVFRQIFVSSXMu&endpointURI=aHR0cDovL3VyaWJ1cm5lci5jb20vc3BhcnFs&isVirtuoso=dHJ1ZQ==&useProxy=dHJ1ZQ==&autocompleteURIs=aHR0cDovL3d3dy53My5vcmcvMjAwMC8wMS9yZGYtc2NoZW1hI2xhYmVs&imageURIs=aHR0cDovL3htbG5zLmNvbS9mb2FmLzAuMS9kZXBpY3Rpb24=&linkURIs=aHR0cDovL3htbG5zLmNvbS9mb2FmLzAuMS9wYWdl&maxRelationLegth=Mg== 
> Once again a demonstration that variety of link types is a big 
> challenge when automatically generating RDF data (link variety is 
> indeed important for the RelFinder).
There is little more to whats going on with URIBurner.

Lets say your understood specific relationships exposed via seeAlso, you 
could knock a simple RDF document and the have URIBurner consume it (or 
just SPARQL the resource from its /sparql), then go back to Relfinder to 
see the effect.

There is something that still isn't quite clear about what I am trying 
to demonstrate re. progressive construction of Linked Data Spaces :-)

Static Data is a commodity with diminishing value. We have to be able to 
move from generality to specificity, in an unobtrusive way re. any Web 
of Linked Data :-)

> Anyways - thanks for the pointer. We are generally interest in 
> integrating further datasets to the RelFinder's default installation 
> (as long as they produce valuable relationships). Further ideas and 
> links are welcome!
> Steffen
> -- 
> Kingsley Idehen schrieb:
>> Steffen,
>> Very cool!
>> Please add: http://uriburner.com/sparql to the default list of SPARQL 
>> endpoints. The effect of doing this ups the implications of this tool 
>> exponentially! Try it yourself e.g. Google to Apple (use the DBpedia 
>> URIs).
>> The density of the graph, the response time provide quite an 
>> experience to the user (especially a Linked Data neophyte).
>> Notes about URIBurner:
>> 1. Quad Store is populated progressively with contributions by anyone 
>> that uses the service to seek structured descriptions of an HTTP 
>> accessible resource via ODE bookmarklets, browser extensions, or 
>> SPARQL FROM Clause that references external Data Sources
>> 2. As part of the graph construction process it not only performs RDF 
>> model transformation (re. non RDF data sources); it also performs LOD 
>> cloud lookups and joins, ditto across 30+ Web 2.0 APIs
>> 3. Anyone with a Virtuoso installation that enables the RDF Mapper 
>> VAD (which is how the Sponger Middleware is packaged) ends up with 
>> their own personal or service specific variant of URIBurner.
>> Again, great stuff, this tool is going to simplify the message, a lot 
>> re., Linked Data and its penchant for serendipitous discovery of 
>> relevant things.



Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 
Received on Monday, 15 March 2010 14:31:09 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:16 UTC