<liclass="toctree-l1 current has-children"><aclass="reference internal"href="../index.html">Comparison</a><inputchecked=""class="toctree-checkbox"id="toctree-checkbox-1"name="toctree-checkbox-1"role="switch"type="checkbox"/><labelfor="toctree-checkbox-1"><divclass="visually-hidden">Toggle navigation of Comparison</div><iclass="icon"><svg><usehref="#svg-arrow-right"></use></svg></i></label><ulclass="current">
<liclass="toctree-l2 has-children"><aclass="reference internal"href="../p2p/index.html">P2P</a><inputclass="toctree-checkbox"id="toctree-checkbox-2"name="toctree-checkbox-2"role="switch"type="checkbox"/><labelfor="toctree-checkbox-2"><divclass="visually-hidden">Toggle navigation of P2P</div><iclass="icon"><svg><usehref="#svg-arrow-right"></use></svg></i></label><ul>
<liclass="toctree-l2 current has-children"><aclass="reference internal"href="index.html">Linked Data</a><inputchecked=""class="toctree-checkbox"id="toctree-checkbox-4"name="toctree-checkbox-4"role="switch"type="checkbox"/><labelfor="toctree-checkbox-4"><divclass="visually-hidden">Toggle navigation of Linked Data</div><iclass="icon"><svg><usehref="#svg-arrow-right"></use></svg></i></label><ulclass="current">
<liclass="toctree-l2 has-children"><aclass="reference internal"href="../data/index.html">Data Structures</a><inputclass="toctree-checkbox"id="toctree-checkbox-5"name="toctree-checkbox-5"role="switch"type="checkbox"/><labelfor="toctree-checkbox-5"><divclass="visually-hidden">Toggle navigation of Data Structures</div><iclass="icon"><svg><usehref="#svg-arrow-right"></use></svg></i></label><ul>
<div><p>However, we envision that different kinds of ldf partitionings will emerge, and that these might even vary dynamically depending on server load. Perhaps a semantic way to express the data, metadata, and hypermedia controls of each fragment will be necessary. -<spanid="id1">[<aclass="reference internal"href="../../references.html#id20"title="Ruben Verborgh, Sam Coppens, Miel Vander Sande, Erik Mannens, Pieter Colpaert, and Rik Van de Walle. Web-Scale Querying through Linked Data Fragments. In Proceedings of the 7th Workshop on Linked Data on the Web. 2014-04-08.">Verborgh <em>et al.</em>, 2014</a>]</span></p>
<p><aclass="reference external"href="https://linkeddatafragments.org/publications/">Linked data fragments</a> are designed to “fill in the middle” between entirely serverside (<spanclass="target"id="index-1"></span>SPARQL) or clientside (downloading a triple store) usage of linked data triples. SPARQL queries are notorious for being resource intensive, as queries can become much more complex than typical relational algebra and the server needs to resolve a potentially enormous number of resources. Placing all the logic on the server, rather than the client, is an architectural decision that has a complex history, but descends from the idea that the web should work by having “agents” that work on the web on our behalf<aclass="footnote-reference brackets"href="#semwebagents"id="id2"role="doc-noteref"><spanclass="fn-bracket">[</span>1<spanclass="fn-bracket">]</span></a>.</p>
<p>Linked data fragments (LDFs) split the difference by placing more of the work on clients, with the server providing <spanclass="target"id="index-2"></span>pre-computed sets of triples for a given selector. “Selector” is a purposefully general concept, but the LDF authors focus primarily on <aclass="reference external"href="https://linkeddatafragments.org/specification/triple-pattern-fragments/">Triple Pattern Fragments</a> that are composed of:</p>
<li><p>A <strong>Triple Pattern</strong>, a <codeclass="docutils literal notranslate"><spanclass="pre">?subject</span><spanclass="pre">?predicate</span><spanclass="pre">?object</span></code> that defines the contents of the fragment</p></li>
<li><p><strong>Metadata</strong>, specifically a <codeclass="docutils literal notranslate"><spanclass="pre">triples</span></code> predicate indicating the estimated total number of triples in the fragment since large fragments need to be paginated, and</p></li>
<li><p><strong>Hypermedia Controls</strong> that can be used to retrieve other related fragments. For example, a triple pattern corresponding to <codeclass="docutils literal notranslate"><spanclass="pre">s:people</span></code><codeclass="docutils literal notranslate"><spanclass="pre">p:named</span></code><codeclass="docutils literal notranslate"><spanclass="pre">o:tom</span></code> would have links to retrieve all the related combinations including each field being unspecified, eg. any triplet whose subject is a <codeclass="docutils literal notranslate"><spanclass="pre">person</span></code>, predicate is <codeclass="docutils literal notranslate"><spanclass="pre">named</span></code> and so on.</p></li>
</ul>
<p>The hosting server then partitions all of the triples in a given dataset into all the possible combinations of subjects, predicates, and objects.</p>
</section>
<sectionid="overlap">
<h2>Overlap<aclass="headerlink"href="#overlap"title="Permalink to this heading">#</a></h2>
<p>p2p-ld follows Linked Data Fragments in that it emphasizes clientside logic rather than query logic on the network. Executing distributed queries with as much logic as SPARQL can embed adds substantial complexity to the protocol and would potentially import a lot of the problems with SPARQL like heightened resource requirements and potential for abuse for denial of service.</p>
<p>LDF is a strategy for (pre-)partitioning a dataset of triples into cacheable chunks, rather than having the server query over the entire graph at once. It also emphasizes querying as iteration: do many small queries in sequence rather than one large query and waiting for the entire result.</p>
<li><p>Primarily, containers are more generic than LDFs. Where LDFs create a deterministic partitioning of a set of triples (all combinations, including wildcards, of each subject, predicate, and object in the dataset), p2p-ld partitions based on meaning and use. They are not mutually exclusive, though - one could also make containers that correspond to the expected LDF format.</p></li>
<li><p>re: <spanclass="target"id="index-3"></span>Linked Data Platform, p2p-ld also concerns “leaf” nodes with binary data accessed via codec, rather than represented as triplets. The results of queries are thus not necessarily imagined to be single factual assertions, but datasets, images, documents, posts, etc. -> So the container concept is less rigidly defined than an LDF host with a completely partitioned triplet graph.</p></li>
<p>Additionally, by being an explicitly <em>social</em> system, p2p-ld is unconcerned with arbitrary query execution on anonymous data systems - the expectation is that individual peers and <spanclass="target"id="index-4"></span>peer federations manage their resources and the norms around their use. Accordingly, they would manage a set of containers (or, the partition of its graph) that</p>
<p>p2p-ld does not attempt to replace or improve SPARQL. There are a number of philosophical and practical differences in the design of the greater semantic web, and particularly its instantiation as bigass corporate knowledge graphs. We will do what we can to integrate with RDF and RDF-like technologies, but p2p-ld is <em>not</em> a distributed SPARQL endpoint.</p>
</div>
</section>
<sectionid="references">
<h2>References<aclass="headerlink"href="#references"title="Permalink to this heading">#</a></h2>
<li><p>Original conference paper: <spanid="id3">[<aclass="reference internal"href="../../references.html#id20"title="Ruben Verborgh, Sam Coppens, Miel Vander Sande, Erik Mannens, Pieter Colpaert, and Rik Van de Walle. Web-Scale Querying through Linked Data Fragments. In Proceedings of the 7th Workshop on Linked Data on the Web. 2014-04-08.">Verborgh <em>et al.</em>, 2014</a>]</span></p></li>
<li><p><spanid="id4">[<aclass="reference internal"href="../../references.html#id19"title="Ruben Verborgh, Miel Vander Sande, Olaf Hartig, Joachim Van Herwegen, Laurens De Vocht, Ben De Meester, Gerald Haesendonck, and Pieter Colpaert. Triple Pattern Fragments: A low-cost knowledge graph interface for the Web. Journal of Web Semantics, 37–38:184–206, 2016-03. URL: https://linkinghub.elsevier.com/retrieve/pii/S1570826816000214 (visited on 2023-06-08), doi:10.1016/j.websem.2016.03.003.">Verborgh <em>et al.</em>, 2016</a>]</span></p></li>
<p>See the history of the early to middle semantic web, discussed in <spanid="id5">[<aclass="reference internal"href="../../references.html#id16"title="Jonny L. Saunders. Surveillance Graphs. 2023-04-02T00:00:00+00:00. URL: https://jon-e.net/surveillance-graphs (visited on 2023-06-08), arXiv:hc:54749, doi:10.17613/syv8-cp10.">Saunders, 2023</a>]</span></p>
