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

Re: LinkedMDB dump?

From: Martynas Jusevičius <martynas@graphity.org>
Date: Fri, 11 Mar 2016 08:47:15 +0000
Message-ID: <CAE35Vmy4GqkgVf8E20i8W4x9tc-7TGWAuz8Kv89pgxLuUYNiDA@mail.gmail.com>
To: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>, Wouter Beek <w.g.j.beek@vu.nl>
Cc: Jean-Claude Moissinac <jean-claude.moissinac@telecom-paristech.fr>, Luca Matteis <lmatteis@gmail.com>, Paul Groth <p.groth@elsevier.com>, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, Semantic Web <semantic-web@w3.org>
There is no reason why the RDF dataset behind SPARQL service should not be
available via another protocol.

Graph Store Protocol standardizes this for triples. For quads one can
simply use standard HTTP semantics.

I.e. if the dataset was exposed over HTTP, a simple GET should retrieve it
all (download the whole dump).


Martynas
graphityhq.com

On Fri, 11 Mar 2016 at 09:12, Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
wrote:

> Hi Wouter,
>
> Thanks for starting this discussion. IMHO, this is a common practical
> issue I've faced several times.
>
> On Fri, Mar 11, 2016 at 8:20 AM, Wouter Beek <w.g.j.beek@vu.nl> wrote:
>>
>>   - Datadumps are inferior to LDF (no triple pattern queries) but
>> superior to SPARQL endpoints (all data can be retrieved).  They are also
>> superior to LDF for the singular use case of obtaining all the data.
>>
>
> Aren't data dumps - Inferior to both LDF and SPARQL service endpoints in
> querybility but superior to both LDF and SPARQL endpoints for obtaining all
> data with one click downloads.
>
> In LDF, a constract query with the simple pattern {?s ?p ?o}, can't I get
> all data with paging? However, this means that I need to have a LDF client
> (can I use the browser client to store this data locally? ).
>
> I also wonder whether implentors of SPARQL services did thought of
> providing (may be non-standard) way to handle this special case.
>
> Best Regards,
> Nandana
>
Received on Friday, 11 March 2016 08:47:55 UTC

This archive was generated by hypermail 2.3.1 : Friday, 11 March 2016 08:47:58 UTC