- From: Martynas Jusevicius <martynas@graphity.org>
- Date: Wed, 19 Mar 2014 12:58:15 +0100
- To: Luca Matteis <lmatteis@gmail.com>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, Linked Data community <public-lod@w3.org>, "semantic-web@w3.org Web" <semantic-web@w3.org>
Ruben, interesting stuff. I remember another project that does something like that: SQUIN http://squin.sourceforge.net/index.shtml How does LDF compare to to it? Thanks, Martynas graphityhq.com On Wed, Mar 19, 2014 at 12:41 PM, Luca Matteis <lmatteis@gmail.com> wrote: > Hi Rueben, > > Just finished reading the paper. Really great stuff. The idea of > splitting a single resourceful SPARQL request into multiple > fine-grained requests was always attractive to me and I've also > thought of something similar (http://lmatteis.github.io/restpark/). I > applaud you and your team for coming up with a formal client algorithm > as well as a server implementation for offering this functionality. > > I wonder, given a Linked Data set, if you could easily and generically > wrap it with a basic LDF interface. Sort of how Pubby wraps SPARQL to > expose Linked Data, maybe there can be a wrapper for a Linked Data > site to expose basic LDF. > > This makes sense because: > > * I build a nice site and my data is available as HTML, marked up with RDFa > * Database is not a triple store, just regular MySQL > > If people want to query this data, they have to crawl all my RDFa > pages and stuck them in their own triple-store. > > Where I see LDF being a *huge* deal is that I could use something to > wrap my RDFa pages and expose a basic LDF server, without having to > change any of my technology stack for my app. This could potentially > allow thousands of RDFa providers to expose querying functionality > with minimum effort. > > Best, > Luca > > > > On Tue, Mar 11, 2014 at 8:27 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote: >> On 3/11/14 12:36 PM, Bernadette Hyland 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 >> >> >> >> Great stuff! >> >> It certainly goes a long way towards making Linked Data's follow-your-nose >> pattern easy to exploit, across SPARQL endpoints. Same applies to anyone >> trying to construct their own pathways over SPARQL endpoints etc.. >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> Twitter Profile: https://twitter.com/kidehen >> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >> >> >> >> >
Received on Wednesday, 19 March 2014 11:58:42 UTC