Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store on-chain data graph #16

Closed
2 tasks
aaronc opened this issue Mar 27, 2019 · 1 comment
Closed
2 tasks

Store on-chain data graph #16

aaronc opened this issue Mar 27, 2019 · 1 comment
Assignees

Comments

@aaronc
Copy link
Member

aaronc commented Mar 27, 2019

Feature: Store on-chain data graph
As an Regen Ledger user
I want to be able to store an RDF data graph
Because I want this data indexed in the global claim database

Given an RDF data graph
When I submit a valid MsgStoreData transaction
Then I should get back the URL for the on-chain data graph

  • wrote docs
  • wrote tests

DEFINITIONS and RATIONALE:
RDF data graph - a format for data graphs that allows indexing in a data store which can use the Sparql query language to query over it. This is advantageous because Sparql has the right features to make it usable as a language for contracts - flexible query expressions over heterogenous data, logic-programming based, and the ability to query external data stores in a single query (Sparql SERVICE)
Global claim database - Regen Ledger provides a global claim database. The data for a claim is represented as an RDF data graph (see W3C Verifiable Claims for some prior work this design is based on). So these on-chain data graphs form the based of the global claim database. The database would also include signatures/verifications of claims but that is covered in other modules

DEV NOTES:

  • MsgStoreData should include the both the data in n-triples format and the hash of the data. The hash should be similar to URDNA2015, but for performance we'll use Blake2b-256 and make blank nodes illegal so we just need to verify that the triples are alphabetized.
  • The data should be identified internally by a data.Address which is the hash of the data plus a one-byte prefix for the type of hash/data storage
  • The URL should be the bech32 encoding of the data.Address with the prefix xrn:d/
  • The goal is to index in a Sparql data store but that will be covered in another issue
@aaronc aaronc added this to the 0.4 milestone Mar 27, 2019
@aaronc aaronc added the backlog label Mar 27, 2019
@aaronc
Copy link
Member Author

aaronc commented Mar 27, 2019

TODO: relate this to #18 instead of n-triples

aaronc added a commit that referenced this issue Mar 29, 2019
CLI was temporarily disable because a suitable text deserializer
needs to be created
@ghost ghost assigned aaronc Mar 29, 2019
@ghost ghost added Status: In Progress and removed backlog labels Mar 29, 2019
@ghost ghost added review and removed Status: In Progress labels Mar 29, 2019
aaronc added a commit that referenced this issue Mar 29, 2019
aaronc added a commit that referenced this issue Mar 29, 2019
aaronc added a commit that referenced this issue Mar 29, 2019
aaronc added a commit that referenced this issue Mar 29, 2019
aaronc added a commit that referenced this issue Mar 29, 2019
aaronc added a commit that referenced this issue Mar 29, 2019
@ghost ghost removed the review label Mar 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant