diff --git a/.buildinfo b/.buildinfo index 7e2ca6a..9a6b0ef 100644 --- a/.buildinfo +++ b/.buildinfo @@ -1,4 +1,4 @@ # Sphinx build info version 1 # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done. -config: 843c5348da5f51068358c85baca3c995 +config: af83c06583f0352802d06c6b3cee9f10 tags: 645f666f9bcd5a90fca523b33c5a78b7 diff --git a/_sources/adapter/index.md.txt b/_sources/adapter/index.md.txt new file mode 100644 index 0000000..eb8922d --- /dev/null +++ b/_sources/adapter/index.md.txt @@ -0,0 +1,11 @@ +# Adapter + +Interfaces to other protocols and formats + +- Files + - hdf5 + - json + - csv + - mat +- HTTP +- S3 \ No newline at end of file diff --git a/_sources/comparison/hypercore.md.txt b/_sources/comparison/hypercore.md.txt index 3396fa3..a94ede7 100644 --- a/_sources/comparison/hypercore.md.txt +++ b/_sources/comparison/hypercore.md.txt @@ -1 +1,8 @@ # Dat/Hypercore + + +```{index} Hypercore; Holepunch +``` +## Holepunch + +https://docs.holepunch.to/ diff --git a/_sources/comparison/index.md.txt b/_sources/comparison/index.md.txt index 375f4a2..585eb10 100644 --- a/_sources/comparison/index.md.txt +++ b/_sources/comparison/index.md.txt @@ -28,6 +28,7 @@ xmpp solid ld_fragments +ld_platform nanopubs ``` @@ -44,16 +45,18 @@ dmc - Arweave - CAN - Chord -- Earthstar +- Earthstar - https://earthstar-project.org/ - Freenet - Manyverse -- P2panda +- P2panda - v interesting! https://p2panda.org/ - SAFE - Storj - [Swarm](https://www.ethswarm.org/swarm-whitepaper.pdf) - not interesting, based around coins and smart contracts - kademlia routing - chunks stored by nodes close in hash space +- Repute.Social +- LinkedTrust.us ## Points of comparison diff --git a/_sources/comparison/ld_fragments.md.txt b/_sources/comparison/ld_fragments.md.txt index 5fdf61d..ea51385 100644 --- a/_sources/comparison/ld_fragments.md.txt +++ b/_sources/comparison/ld_fragments.md.txt @@ -2,11 +2,16 @@ ``` # Linked Data Fragments +[Containers](Containers) are one example of: + + +> 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. -{cite}`verborghWebScaleQueryingLinked2014` + ## Summary [Linked data fragments](https://linkeddatafragments.org/publications/) are designed to "fill in the middle" between entirely serverside ({index}`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[^semwebagents]. -Linked data fragments (LDFs) split the difference by placing more of the work on clients, with the server providing pre-computed sets of triples for a given selector. "Selector" is a purposefully general concept, but the LDF authors focus primarily on [Triple Pattern Fragments](https://linkeddatafragments.org/specification/triple-pattern-fragments/) that are composed of: +Linked data fragments (LDFs) split the difference by placing more of the work on clients, with the server providing {index}`pre-computed sets of triples ` for a given selector. "Selector" is a purposefully general concept, but the LDF authors focus primarily on [Triple Pattern Fragments](https://linkeddatafragments.org/specification/triple-pattern-fragments/) that are composed of: - A **Triple Pattern**, a `?subject ?predicate ?object` that defines the contents of the fragment - **Metadata**, specifically a `triples` predicate indicating the estimated total number of triples in the fragment since large fragments need to be paginated, and @@ -16,15 +21,18 @@ The hosting server then partitions all of the triples in a given dataset into al ## Overlap -p2p-ld follows Linked Data Fragments in that it emphasizes clientside logic rather than query logic on the network. Executing distributed complex queries 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. +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. +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. ## Differences -- re: 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. +- 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. -Additionally, by being an explicitly *social* system, p2p-ld is unconcerned with arbitrary query execution time on anonymous data systems - the expectation is that individual peers and {index}`peer federations ` +- re: {index}`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. + +Additionally, by being an explicitly *social* system, p2p-ld is unconcerned with arbitrary query execution on anonymous data systems - the expectation is that individual peers and {index}`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 ```{admonition} To be very clear! @@ -33,8 +41,6 @@ Additionally, by being an explicitly *social* system, p2p-ld is unconcerned with 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 *not* a distributed SPARQL endpoint. ``` -There are a number of philosophical - [^semwebagents]: See the history of the early to middle semantic web, discussed in {cite}`saundersSurveillanceGraphs2023` diff --git a/_sources/comparison/ld_platform.md.txt b/_sources/comparison/ld_platform.md.txt new file mode 100644 index 0000000..f7e8d54 --- /dev/null +++ b/_sources/comparison/ld_platform.md.txt @@ -0,0 +1,103 @@ +```{index} Linked Data; Platform +``` +# Linked Data Platform + +```{index} Containers +``` +## Containers + +https://www.w3.org/TR/ldp/#ldpc + +We extend the notion of LDP containers! + +Terms: +- Containment Triples +- Membership Triples + +Types: +- Direct Containers + +```turtle +@prefix dcterms: . +@prefix ldp: . + + + a ldp:BasicContainer; + dcterms:title "A very simple container"; + ldp:contains , , . +``` + +- Indirect Containers - a way of interacting with existing data + +Given: + +```turtle +@prefix ldp: . +@prefix o: . + + + a o:NetWorth; + o:netWorthOf ; + o:asset + , + ; + o:liability + , + , + . +``` + +we can make direct containers that describe the assets and liabilities as containers without modifying the original data + +```turtle +@prefix ldp: . +@prefix dcterms: . +@prefix o: . + + + a ldp:DirectContainer; + dcterms:title "The assets of JohnZSmith"; + ldp:membershipResource ; + ldp:hasMemberRelation o:asset; + ldp:contains , . +``` + +Additionally, if one were to add a new set of "advisors," we would make an indirect container that tells us we need an additional triple when creating new members of the container (`foaf:primaryTopic`): + +```turtle + + a ldp:IndirectContainer; + dcterms:title "The asset advisors of JohnZSmith"; + ldp:membershipResource <>; + ldp:hasMemberRelation o:advisor; + ldp:insertedContentRelation foaf:primaryTopic; + ldp:contains + , # URI of a document a.k.a. an information resource + . # describing a person +``` + +(still unclear to me what is different about that, still reading.) + +| Completed Request | Membership Effect | Containment Effect | +| ----------------- | ------------------- | ------------------ | +| Create in Basic Container | New triple: (LDPC, ldp:contains, LDPR) | Same +| Create in Direct Container | New triple links LDP-RS to created LDPR. LDP-RS URI may be same as LDP-DC | New triple: (LDPC, ldp:contains, LDPR) | +| Create in Indirect Container | New triple links LDP-RS to content indicated URI | New triple: (LDPC, ldp:contains, LDPR) | +| Resource deleted | Membership triple may be removed | (LDPC, ldp:contains, LDPR) triple is removed | +| Container deleted | Triples and member resources may be removed | Triples of form (LDPC, ldp:contains, LDPR) and contained LDPRs may be removed | + +## Similarities + +- Separation between container data and metadata - "minimal-container triples," what remains in the container when the container has zero members and zero contained resources + + +## Differences + +- Containers are not recursive??or at least that is suggested by the 'net worth' example that explains why we can't just turn the original subject into a container: "can't mix assets and liabilities" and i am like why not make one container for the person and then subcontainers for each of the types? + + +## References + +- Spec: https://www.w3.org/TR/ldp/ +- Use cases and requirements: https://www.w3.org/TR/ldp-ucr/ +- eg. using virtuoso. https://github.com/vemonet/virtuoso-ldp \ No newline at end of file diff --git a/_sources/comparison/ssb.md.txt b/_sources/comparison/ssb.md.txt index edab114..ad4a844 100644 --- a/_sources/comparison/ssb.md.txt +++ b/_sources/comparison/ssb.md.txt @@ -1 +1,92 @@ +```{index} Protocol; Secure Scuttlebutt +``` # Secure Scuttlebutt + + + +## Feeds & Metafeeds + +- Peers maintain a list of feeds they subscribe to +- When peers connect, they ask for updates to subscribed feeds +- Metafeeds can provide metadata about other feeds, and can form a tree structure with other Metafeeds as subfeeds. + - {index}`Bencoded ` rather than JSON. + +```{mermaid} +flowchart LR + subgraph Main [Main Feed] + mf["`Main Feed Posts + *metafeed/announce* + message`"] + end + subgraph Meta [Meta feed] + direction TB + mf1["`Metafeed posts + *metafeed/add/existing + message`"] + mf2["`Metafeed posts + *metafeed/add/existing + message`"] + mf3["`Metafeed posts + *metafeed/add/derived + message`"] + mf4["`Metafeed posts + *metafeed/add/existing + message`"] + mf1 --> mf2 + mf2 --> mf3 + mf3 --> mf4 + end + + subgraph SubfeedA [Subfeed A] + direction LR + sfa1["`Application specific + message in subfeed`"] + sfa2["`Application specific + message in subfeed`"] + sfa1 --> sfa2 + end + subgraph SubfeedB [Subfeed B] + direction LR + sfb1["`Application specific + message in subfeed`"] + sfb2["`Application specific + message in subfeed`"] + sfb1 --> sfb2 + end + subgraph SubfeedC [Subfeed C] + direction LR + sfc1["`Application specific + message in subfeed`"] + sfc2["`Application specific + message in subfeed`"] + sfc1 --> sfc2 + end + subgraph SubfeedD [Subfeed D] + direction LR + sfd1["`Application specific + message in subfeed`"] + sfd2["`Application specific + message in subfeed`"] + sfd1 --> sfd2 + end + + Main --> Meta + Meta --> SubfeedA + Meta --> SubfeedB + Meta --> SubfeedC + Meta --> SubfeedD +``` + +Uses for metafeeds + +- Storing multiple network identities with a special feed off the user's root metafeed. (contents of metafeed entries can be encrypted) +- Allow for multiple devices to use the same identity - https://github.com/ssbc/fusion-identity-spec + - Device A `invite`s Device B to identity + - Device B `consent`s + - Device A `entrust`s phone with private key + - Device B posts a `proof-of-key` message + - If device B lost, `tombstone` the fusion identity message + +## References + +- https://ssbc.github.io/scuttlebutt-protocol-guide/ \ No newline at end of file diff --git a/_sources/comparison/xmpp.md.txt b/_sources/comparison/xmpp.md.txt index d7accf9..53f06ff 100644 --- a/_sources/comparison/xmpp.md.txt +++ b/_sources/comparison/xmpp.md.txt @@ -4,4 +4,6 @@ Stuff we like about XMPP - Resources like `username@domain.com/resource` for indicating different accounts and contexts. - Service discovery - https://xmpp.org/extensions/xep-0030.html -- Protocol interoperability \ No newline at end of file +- Protocol interoperability +- https://en.wikipedia.org/wiki/BOSH_(protocol) +- https://en.wikipedia.org/wiki/Jingle_(protocol) \ No newline at end of file diff --git a/_sources/data_structures.md.txt b/_sources/data_structures.md.txt index 8808eba..df2e684 100644 --- a/_sources/data_structures.md.txt +++ b/_sources/data_structures.md.txt @@ -7,6 +7,7 @@ Triplet graphs similar to linked data fragments with envelopes. decoupling conte - Versioning - Typed objects with formatting +(Containers)= ## Containers - Packets of LD-triplets that contain @@ -30,6 +31,8 @@ Triplet graphs similar to linked data fragments with envelopes. decoupling conte - Capabilities: A container can specify different capabilities that another account can take (eg. "Like", "Upvote", "Reply") - Capabilities should also contain a permissions scope, if none is present, the global scope is assumed. - Since Identities are just a special form of container, they too can advertise different actions that they support with capabilities. +- Basically a container is a merkle DAG with binary data at its leaves a la the {index}`Linked Data; Platform` +- Re: Ordering - https://github.com/ssbc/ssb-tangle Re hashing a graph: the container always has one root node that is the container's identity from which a graph traversal starts. A {index}`Merkle DAG` is then constructed starting from the leaves. diff --git a/_sources/design.md.txt b/_sources/design.md.txt index 29e6def..8f85afc 100644 --- a/_sources/design.md.txt +++ b/_sources/design.md.txt @@ -25,4 +25,8 @@ Names and locations are *linguistic* not *mathematical.* Rather than trying to d We should neither sacrifice control of the internet to platform giants nor should we insist that self-hosting is the only alternative. If the alternative to using Google Docs or Slack requires me to be a professional sysadmin, or even to keep a raspberry pi plugged in and online at all times, it isn't an alternative for 95% of people. -It should be possible to share resources such that relatively few people need to maintain persistent network infrastructure, and it should be possible to accomodate their leaving at any time. It should also be very difficult for one or a few actors to make a large number of other peers on the network dependent on them, claiming de-facto control over an ostensibly decentralized system (lookin at you mastodon.social). \ No newline at end of file +It should be possible to share resources such that relatively few people need to maintain persistent network infrastructure, and it should be possible to accomodate their leaving at any time. It should also be very difficult for one or a few actors to make a large number of other peers on the network dependent on them, claiming de-facto control over an ostensibly decentralized system (lookin at you mastodon.social). + +## Lack of Agency is a tighter bottleneck than Performance + +(rather than optimizing for performance of massive queries over huge datasets, we optimize for the ability for individual people to organize the resources that would be relevant to them. The thing that is limiting our ability to make sense of data in neuroscience, for example, is not that our servers aren't fast enough, but the barriers to making well-structured data are too high, as is the expertise to conduct large scale queries. Even then, our ability to *understand* and *make sense of* the information is even less constrained by performance, and more by the absence of infrastructure to link and communicate heterogeneous things. We focus on small-scale computing not only for ethical reasons, but also practical ones.) \ No newline at end of file diff --git a/_sources/discovery.md.txt b/_sources/discovery.md.txt index 6b84d94..295aba3 100644 --- a/_sources/discovery.md.txt +++ b/_sources/discovery.md.txt @@ -4,10 +4,20 @@ How do we find people and know how to connect to them? - Bootstrapping initial connections - Gossiping -- Hole punching + +```{index} Hole Punching +``` +## Hole Punching + +- https://tailscale.com/blog/how-nat-traversal-works/ +- {index}`Hypercore` + - See: https://docs.holepunch.to/apps/keet.io + - https://github.com/mafintosh/dht-rpc + - https://docs.holepunch.to/building-blocks/hyperdht +- Socket Supply Co -# Scraps +## Scraps https://xmpp.org/extensions/xep-0030.html @@ -18,3 +28,5 @@ https://xmpp.org/extensions/xep-0030.html > - any additional items associated with the entity, whether or not they are addressable as JIDs > > All three MUST be supported, but the first two kinds of information relate to the entity itself whereas the third kind of information relates to items associated with the entity itself; therefore two different query types are needed. + +- subscription to particular data types or query patterns - each peer keeps a list of things that we should tell it about when we make a new graph. So I might want to always see new posts and pre-emptively index those but I don't care about your datasets. This should probably exist at the level of a peer relationship rather than a peer outbox-like thing diff --git a/_sources/index.md.txt b/_sources/index.md.txt index 9ae263f..d9ac97e 100644 --- a/_sources/index.md.txt +++ b/_sources/index.md.txt @@ -41,7 +41,8 @@ evolvability :hidden: triplets -translation +adapter/index +translation/index ``` ```{toctree} diff --git a/_sources/querying.md.txt b/_sources/querying.md.txt index 4900310..c81f6dc 100644 --- a/_sources/querying.md.txt +++ b/_sources/querying.md.txt @@ -2,12 +2,14 @@ How do we find peers that have subgraphs that are responsive to what we want? -## Syntax +- Query results should then become their own containers, with the component triplets of the query being hashed at the root level, so then the query-er can cache the query results (in case anyone else makes the same query) while also rehosting the original containers returned from the query. +## Syntax + (qlocation)= ### Location -How to refer to a given [container](data_structures.html#Containers), eg. +How to refer to a given [container](Containers), eg. ``` @user:containerName:childName @@ -20,7 +22,6 @@ or numerically ``` -Children ### Version @@ -30,4 +31,4 @@ References without version qualification indicate the most recent version at the ## Query Fragments -Using blank subgraphs to specify queries \ No newline at end of file +Using blank subgraphs to specify queries like {index}`Linked Data; Fragments` and {index}`SPARQL` \ No newline at end of file diff --git a/_sources/sketchpad.md.txt b/_sources/sketchpad.md.txt index b80ffac..9b9ba37 100644 --- a/_sources/sketchpad.md.txt +++ b/_sources/sketchpad.md.txt @@ -29,3 +29,8 @@ erDiagram - Triplets - Containers - Codecs + + +## Random notes + +- re: {index}`Backlinks` - https://lists.w3.org/Archives/Public/public-rdf-comments/2012Jul/0007.html diff --git a/_sources/translation/index.md.txt b/_sources/translation/index.md.txt new file mode 100644 index 0000000..b102829 --- /dev/null +++ b/_sources/translation/index.md.txt @@ -0,0 +1,4 @@ +# Translation + +Translation/import of existing schema/formats. + diff --git a/adapter/index.html b/adapter/index.html new file mode 100644 index 0000000..3b28e7f --- /dev/null +++ b/adapter/index.html @@ -0,0 +1,318 @@ + + + + + + + + + + Adapter - p2p-ld 0.1.0 documentation + + + + + + + + + + + + + + + + Contents + + + + + + Menu + + + + + + + + Expand + + + + + + Light mode + + + + + + + + + + + + + + Dark mode + + + + + + + Auto light/dark mode + + + + + + + + + + + + + + + + + + + +
+
+
+ +
+
+
p2p-ld 0.1.0 documentation
 +
+
+
+ +
+ +
+
+ +
+
+
+ + + + + Back to top + +
+ +
+ +
+ +
+
+
+

Adapter#

+

Interfaces to other protocols and formats

+
    +

  • Files

    +
      +

    • hdf5

      • +

    • json

      • +

    • csv

      • +

    • mat

      • +
    +
    • +

  • HTTP

    • +

  • S3

    • +
+
+ +
+
+ +
+ +
+
+ + + + + \ No newline at end of file diff --git a/backwards_compatibility.html b/backwards_compatibility.html index 9545382..3c229fb 100644 --- a/backwards_compatibility.html +++ b/backwards_compatibility.html @@ -3,11 +3,11 @@ - + - 12. Backwards Compatibility - p2p-ld 0.1.0 documentation + 11. Backwards Compatibility - p2p-ld 0.1.0 documentation @@ -171,6 +171,7 @@
  • XMPP
  • SOLID
  • Linked Data Fragments
    • +
  • Linked Data Platform
  • NanoPubs
  • ERIS
  • DMC
    • @@ -185,20 +186,20 @@
  • 2. Protocol
  • 3. Identity
  • 4. Discovery
    • -
  • 5. Scraps
    • -
  • 6. Data Structures
    • -
  • 7. Vocabulary
    • -
  • 8. Querying
    • -
  • 9. Encryption
    • -
  • 10. TODO
    • -
  • 11. Federation
    • -
  • 12. Backwards Compatibility
    • -
  • 13. Evolvability
    • +
  • 5. Data Structures
    • +
  • 6. Vocabulary
    • +
  • 7. Querying
    • +
  • 8. Encryption
    • +
  • 9. TODO
    • +
  • 10. Federation
    • +
  • 11. Backwards Compatibility
    • +
  • 12. Evolvability

    • Ecosystem

    Drafting

    diff --git a/comparison/ipfs.html b/comparison/ipfs.html index efb8aa8..2fe815c 100644 --- a/comparison/ipfs.html +++ b/comparison/ipfs.html @@ -171,6 +171,7 @@
  • XMPP
  • SOLID
  • Linked Data Fragments
    • +
  • Linked Data Platform
  • NanoPubs
  • ERIS
  • DMC
    • @@ -185,20 +186,20 @@
  • 2. Protocol
  • 3. Identity
  • 4. Discovery
    • -
  • 5. Scraps
    • -
  • 6. Data Structures
    • -
  • 7. Vocabulary
    • -
  • 8. Querying
    • -
  • 9. Encryption
    • -
  • 10. TODO
    • -
  • 11. Federation
    • -
  • 12. Backwards Compatibility
    • -
  • 13. Evolvability
    • +
  • 5. Data Structures
    • +
  • 6. Vocabulary
    • +
  • 7. Querying
    • +
  • 8. Encryption
    • +
  • 9. TODO
    • +
  • 10. Federation
    • +
  • 11. Backwards Compatibility
    • +
  • 12. Evolvability

    • Ecosystem

    Drafting

    Ecosystem

    Drafting

      @@ -245,10 +246,14 @@

      Linked Data Fragments#

      +

      Containers are one example of:

      +
      +

      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. -[Verborgh et al., 2014]

      +

      Summary#

      -

      Linked data fragments are designed to “fill in the middle” between entirely serverside (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[1].

      -

      Linked data fragments (LDFs) split the difference by placing more of the work on clients, with the server providing pre-computed sets of triples for a given selector. “Selector” is a purposefully general concept, but the LDF authors focus primarily on Triple Pattern Fragments that are composed of:

      +

      Linked data fragments are designed to “fill in the middle” between entirely serverside (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[1].

      +

      Linked data fragments (LDFs) split the difference by placing more of the work on clients, with the server providing pre-computed sets of triples for a given selector. “Selector” is a purposefully general concept, but the LDF authors focus primarily on Triple Pattern Fragments that are composed of:

      • A Triple Pattern, a ?subject ?predicate ?object that defines the contents of the fragment

      • Metadata, specifically a triples predicate indicating the estimated total number of triples in the fragment since large fragments need to be paginated, and

        • @@ -258,19 +263,20 @@

      Overlap#

      -

      p2p-ld follows Linked Data Fragments in that it emphasizes clientside logic rather than query logic on the network. Executing distributed complex queries 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.

      +

      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.

      +

      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.

      Differences#

        -

      • re: 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.

        • +

      • 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.

        • +

      • re: 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.

      -

      Additionally, by being an explicitly social system, p2p-ld is unconcerned with arbitrary query execution time on anonymous data systems - the expectation is that individual peers and peer federations

      +

      Additionally, by being an explicitly social system, p2p-ld is unconcerned with arbitrary query execution on anonymous data systems - the expectation is that individual peers and 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

      To be very clear!

      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 not a distributed SPARQL endpoint.

      -

      There are a number of philosophical

      References#

      @@ -278,8 +284,8 @@

    • Homepage: https://linkeddatafragments.org/

    • Papers:

    • Specification: Triple Pattern Fragments

      • @@ -287,8 +293,8 @@
      @@ -299,12 +305,12 @@
      - +
      Next
      -
      NanoPubs
      +
      Linked Data Platform
       diff --git a/comparison/ld_platform.html b/comparison/ld_platform.html new file mode 100644 index 0000000..cbbed4a --- /dev/null +++ b/comparison/ld_platform.html @@ -0,0 +1,447 @@ + + + + + + + + + + Linked Data Platform - p2p-ld 0.1.0 documentation + + + + + + + + + + + + + + + + Contents + + + + + + Menu + + + + + + + + Expand + + + + + + Light mode + + + + + + + + + + + + + + Dark mode + + + + + + + Auto light/dark mode + + + + + + + + + + + + + + + + + + + +
      +
      +
      + +
      +
      +
      p2p-ld 0.1.0 documentation
       +
      +
      +
      + +
      + +
      +
      + +
      +
      +
      + + + + + Back to top + +
      + +
      + +
      + +
      +
      +
      +

      Linked Data Platform#

      +
      +

      Containers#

      +

      https://www.w3.org/TR/ldp/#ldpc

      +

      We extend the notion of LDP containers!

      +

      Terms:

      +
        +

      • Containment Triples

        • +

      • Membership Triples

        • +
      +

      Types:

      +
        +

      • Direct Containers

        • +
      +
      @prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/c1/>
+   a ldp:BasicContainer;
+   dcterms:title "A very simple container";
+   ldp:contains <r1>, <r2>, <r3>.
+
      +
      +
        +

      • Indirect Containers - a way of interacting with existing data

        • +
      +

      Given:

      +
      @prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology#>.
+
+<http://example.org/netWorth/nw1/>
+   a o:NetWorth;
+   o:netWorthOf <http://example.org/users/JohnZSmith>;
+   o:asset 
+      <assets/a1>,
+      <assets/a2>;
+   o:liability 
+      <liabilities/l1>,
+      <liabilities/l2>,
+      <liabilities/l3>.
+
      +
      +

      we can make direct containers that describe the assets and liabilities as containers without modifying the original data

      +
      @prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix o: <http://example.org/ontology#>.
+
+<http://example.org/netWorth/nw1/assets/>
+   a ldp:DirectContainer;
+   dcterms:title "The assets of JohnZSmith";
+   ldp:membershipResource <http://example.org/netWorth/nw1/>;
+   ldp:hasMemberRelation o:asset;
+   ldp:contains <a1>, <a2>.
+
      +
      +

      Additionally, if one were to add a new set of “advisors,” we would make an indirect container that tells us we need an additional triple when creating new members of the container (foaf:primaryTopic):

      +
      <advisors/>
+   a ldp:IndirectContainer;
+   dcterms:title "The asset advisors of JohnZSmith";
+   ldp:membershipResource <>;
+   ldp:hasMemberRelation o:advisor;
+   ldp:insertedContentRelation foaf:primaryTopic;
+   ldp:contains
+   	 <advisors/bob>,     # URI of a document a.k.a. an information resource
+   	 <advisors/marsha>.  # describing a person
+
      +
      +

      (still unclear to me what is different about that, still reading.)

      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

      Completed Request

      Membership Effect

      Containment Effect

      Create in Basic Container

      New triple: (LDPC, ldp:contains, LDPR)

      Same

      Create in Direct Container

      New triple links LDP-RS to created LDPR. LDP-RS URI may be same as LDP-DC

      New triple: (LDPC, ldp:contains, LDPR)

      Create in Indirect Container

      New triple links LDP-RS to content indicated URI

      New triple: (LDPC, ldp:contains, LDPR)

      Resource deleted

      Membership triple may be removed

      (LDPC, ldp:contains, LDPR) triple is removed

      Container deleted

      Triples and member resources may be removed

      Triples of form (LDPC, ldp:contains, LDPR) and contained LDPRs may be removed

      +
      +
      +
      +

      Similarities#

      +
        +

      • Separation between container data and metadata - “minimal-container triples,” what remains in the container when the container has zero members and zero contained resources

        • +
      +
      +
      +

      Differences#

      +
        +

      • Containers are not recursive??or at least that is suggested by the ‘net worth’ example that explains why we can’t just turn the original subject into a container: “can’t mix assets and liabilities” and i am like why not make one container for the person and then subcontainers for each of the types?

        • +
      +
      +
      +

      References#

      + +
      +
      + +
      +
      + +
      + +
      +
      + + + + + \ No newline at end of file diff --git a/comparison/matrix.html b/comparison/matrix.html index 9e5fd13..82fb76f 100644 --- a/comparison/matrix.html +++ b/comparison/matrix.html @@ -171,6 +171,7 @@
    • XMPP
    • SOLID
    • Linked Data Fragments
      • +
    • Linked Data Platform
    • NanoPubs
    • ERIS
    • DMC
      • @@ -185,20 +186,20 @@
    • 2. Protocol
    • 3. Identity
    • 4. Discovery
      • -
    • 5. Scraps
      • -
    • 6. Data Structures
      • -
    • 7. Vocabulary
      • -
    • 8. Querying
      • -
    • 9. Encryption
      • -
    • 10. TODO
      • -
    • 11. Federation
      • -
    • 12. Backwards Compatibility
      • -
    • 13. Evolvability
      • +
    • 5. Data Structures
      • +
    • 6. Vocabulary
      • +
    • 7. Querying
      • +
    • 8. Encryption
      • +
    • 9. TODO
      • +
    • 10. Federation
      • +
    • 11. Backwards Compatibility
      • +
    • 12. Evolvability

    Ecosystem

    Drafting

    Ecosystem

    Drafting

    Ecosystem

    Drafting

    Ecosystem

    Drafting

    Ecosystem

    Drafting

    Ecosystem

    Drafting

      @@ -237,14 +238,109 @@ -

    Ecosystem

    Drafting

      @@ -254,6 +255,8 @@

  • Protocol interoperability

    • +

  • https://en.wikipedia.org/wiki/BOSH_(protocol)

    • +

  • https://en.wikipedia.org/wiki/Jingle_(protocol)

    • diff --git a/data_structures.html b/data_structures.html index d09fa7f..e91112b 100644 --- a/data_structures.html +++ b/data_structures.html @@ -3,11 +3,11 @@ - + - 6. Data Structures - p2p-ld 0.1.0 documentation + 5. Data Structures - p2p-ld 0.1.0 documentation @@ -171,6 +171,7 @@
  • XMPP
  • SOLID
  • Linked Data Fragments
    • +
  • Linked Data Platform
  • NanoPubs
  • ERIS
  • DMC
    • @@ -185,20 +186,20 @@
  • 2. Protocol
  • 3. Identity
  • 4. Discovery
    • -
  • 5. Scraps
    • -
  • 6. Data Structures
    • -
  • 7. Vocabulary
    • -
  • 8. Querying
    • -
  • 9. Encryption
    • -
  • 10. TODO
    • -
  • 11. Federation
    • -
  • 12. Backwards Compatibility
    • -
  • 13. Evolvability
    • +
  • 5. Data Structures
    • +
  • 6. Vocabulary
    • +
  • 7. Querying
    • +
  • 8. Encryption
    • +
  • 9. TODO
    • +
  • 10. Federation
    • +
  • 11. Backwards Compatibility
    • +
  • 12. Evolvability

    • Ecosystem

    Drafting

      @@ -244,7 +245,7 @@
      -

      6. Data Structures#

      +

      5. Data Structures#

      Triplet graphs similar to linked data fragments with envelopes. decoupling content addressing from versioning

      • Merkel DAGs

        • @@ -253,7 +254,7 @@

      • Typed objects with formatting

      -

      6.1. Containers#

      +

      5.1. Containers#

      • Packets of LD-triplets that contain

          @@ -294,11 +295,13 @@

        • Since Identities are just a special form of container, they too can advertise different actions that they support with capabilities.

        • +

      • Basically a container is a merkle DAG with binary data at its leaves a la the Linked Data; Platform

        • +

      • Re: Ordering - https://github.com/ssbc/ssb-tangle

      -

      Re hashing a graph: the container always has one root node that is the container’s identity from which a graph traversal starts. A Merkle DAG is then constructed starting from the leaves.

      +

      Re hashing a graph: the container always has one root node that is the container’s identity from which a graph traversal starts. A Merkle DAG is then constructed starting from the leaves.

      -

      6.2. Triplets#

      +

      5.2. Triplets#

      • Triplet format

          @@ -315,10 +318,10 @@
      -

      6.3. Schema#

      +

      5.3. Schema#

      -

      6.4. Codecs#

      +

      5.4. Codecs#

      See IPLD Codecs and Linked Data Platform spec

      Means of interacting with binary data.

      Describes

      @@ -328,7 +331,7 @@
    -

    6.5. Versioning#

    +

    5.5. Versioning#

    +
    +

    Lack of Agency is a tighter bottleneck than Performance#

    +

    (rather than optimizing for performance of massive queries over huge datasets, we optimize for the ability for individual people to organize the resources that would be relevant to them. The thing that is limiting our ability to make sense of data in neuroscience, for example, is not that our servers aren’t fast enough, but the barriers to making well-structured data are too high, as is the expertise to conduct large scale queries. Even then, our ability to understand and make sense of the information is even less constrained by performance, and more by the absence of infrastructure to link and communicate heterogeneous things. We focus on small-scale computing not only for ethical reasons, but also practical ones.)

    +
    @@ -285,7 +290,7 @@ - +
    @@ -331,6 +336,7 @@
  • Permanence is Impossible
  • Ambiguity is Natural
  • Autonomy and Convenience Can Coexist
    • +
  • Lack of Agency is a tighter bottleneck than Performance
    • diff --git a/discovery.html b/discovery.html index c0b3b9a..208c9b9 100644 --- a/discovery.html +++ b/discovery.html @@ -3,7 +3,7 @@ - + @@ -135,7 +135,7 @@
    -
    -