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

Re: Linked Data Fragments: Web-scale querying

From: Bernadette Hyland <bhyland@3roundstones.com>
Date: Tue, 11 Mar 2014 12:36:52 -0400
Cc: Linked Data community <public-lod@w3.org>, "semantic-web@w3.org Web" <semantic-web@w3.org>
Message-Id: <5FFAD6AB-1ADC-486E-B83D-983372893BF2@3roundstones.com>
To: Ruben Verborgh <ruben.verborgh@ugent.be>
Hi Ruben, 
This is really nicely presented and easy to understand.  Thank you for announcing this project, clearly articulating the problem you're trying to address and providing a mechanism to quickly demo it.  In < 2 minutes I was able to see what your team at Ghent University is doing -- well done!  My team & I are looking forward to digging into it further.  Thank you & I hope it receives good uptake.  Please keep these lists updated.

Cheers,

Bernadette Hyland
CEO, 3 Round Stones, Inc.
Arlington, VA USA

On Mar 11, 2014, at 8:06 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:

> Dear Semantic Web and Linked Data enthusiasts,
> 
> If you're curious about new ways to query Linked Data,
> you might like our Linked Data Fragments client.
> It lets your browser execute SPARQL queries over Web data
> in a scalable way: http://client.linkeddatafragments.org/
> 
> Today's answer to Web querying consists of SPARQL endpoints.
> Publishers of data sets offer a public endpoint, which
> answers highly specific questions for any client. Unfortunately,
> the availability of public SPARQL endpoints is problematic [1] –
> and thus so is the availability of publicly queryable datasets.
> We cannot rely on them for building applications, and that's a pity.
> 
> It is not an issue of performance but an inherent architectural issue:
> making a public server responsible for arbitrarily complex requests
> doesn't work on a Web scale. We have to create more simple servers,
> only answering simple questions that don't endanger availability.
> Yet at the same time, the dataset should remain easily queryable.
> 
> This is the goal of the Linked Data Fragments project [2].
> “Linked Data Fragments” is a term for all ways to offer parts of a dataset:
> - SPARQL results are (precise but expensive) Linked Data Fragments.
> - Data dumps are (huge but straightforward) Linked Data Fragments.
> Between those two extremes, an underexplored range of fragments exists.
> 
> We propose a new type called “basic Linked Data Fragments”,
> which partitions a dataset in all its basic triple patterns.
> This reconciles the need for queryable public datasets
> with the availability demands of Web applications.
> A basic Linked Data Fragments server with well-known datasets
> is available online [3] (and so is its source code [4]).
> 
> Try our online client [5] that answers SPARQL queries
> using only basic Linked Data Fragments (source code [6]).
> It works up to two magnitudes faster than Linked Data Querying [7]
> because servers offers those fragments that assist client-side querying –
> without needing to solve expensive queries at the server side.
> 
> Basic Linked Data Fragments are not a definitive answer;
> there are many other types of fragments to explore.
> However, you might be surprised to see quite acceptable query times,
> and – most importantly – high availability and scalability.
> 
> Read more on Linked Data Fragments on the website
> http://linkeddatafragments.org/ and discover all details
> in our forthcoming LDOW2014 publication [8].
> 
> Looking forward to your feedback!
> 
> Best regards,
> 
> Ruben Verborgh
> Ghent University – iMinds, Belgium
> 
> 
> [1] http://sw.deri.org/~aidanh/docs/epmonitorISWC.pdf
> [2] http://linkeddatafragments.org/
> [3] http://data.linkeddatafragments.org/
> [4] https://github.com/LinkedDataFragments/Server
> [5] http://client.linkeddatafragments.org/
> [6] https://github.com/LinkedDataFragments/Client
> [7] https://cs.uwaterloo.ca/~ohartig/files/Hartig_LDQueryExec_DBSpektrum2013_Preprint.pdf
> [8] http://linkeddatafragments.org/publications/ldow2014.pdf
> 


Received on Tuesday, 11 March 2014 16:39:25 UTC

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