W3C home > Mailing lists > Public > public-interledger@w3.org > February 2016

Ledgers and semantic Web was: Stellar launches - Ripple-like decentralized ledger

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 18 Feb 2016 07:48:07 +0000
Cc: Web Payments CG <public-webpayments@w3.org>, Interledger Community Group <public-interledger@w3.org>
Message-Id: <048F2608-B778-4F73-B82E-1ED452367114@bblfish.net>
To: Adrian Hope-Bailie <adrian@hopebailie.com>

> On 18 Feb 2016, at 07:16, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
> 
> Not at all. My point was that no single distributed ledger will ever handle all of the world's transactions. i.e. The world should not be standardizing on a single ledger but rather on a protocol for interoperability between ledgers.

Hi,
 
   I think this is a good observation to start off with.  As I see it a Ledger needs to be built out of the following components

a. some way of encoding relations whatever they are in a global space ( data )
b. some way of signing that encoding
c. some way of distributing the data
d. a consensus protocol

Take the points above 1 by 1:

(a) As it happens the data part s the problem that the W3C  RDF standards solve. It allows data to be published in a global space (no name clashes because all entities are identified with Universal Resource Locators URIs), with no center of control to specify the vocabularies needed (just like the web, and entity can create it's own URIs), an easy way to discover the meaning of terms ( dereference the URI, if it's an HTTP URI do a GET on it, if it is an ipfs URI do a ...), a story about logic, and a large number of serialisations to suite people's preferences (RDF/XML, Turtle, JSON-LD, and more relevantly here perhaps even a binary format ( https://www.w3.org/Submission/2011/SUBM-HDT-20110330/ <https://www.w3.org/Submission/2011/SUBM-HDT-20110330/> ). There are tools for it, there are university deparments to help with teaching it around the world, there are institutions, books, jobs, very large deployments, see http://lod-cloud.net/ <http://lod-cloud.net/>


(b) we have ways of signing graphs, without also needing to serialise them to a specific encoding
  https://web-payments.org/specs/source/ld-signatures/ <https://web-payments.org/specs/source/ld-signatures/>
  This means you can sign a graph in any of the encodings mentioned above, and the signature will be the same. The JSON-LD signature will be the same as the binary one. There is no need to save two copies of your data: the serialisation and the data as you do with say JOSE.

(c) each URI type comes with its' own protocol. So http:// URLs come with the HTTP protocol, ipfs:// URLs come with ipfs protocol, etc... RDF can easily allow you to link between protocols, as it is built at the URI level.
This means that as you move to ledgers in RDF based say on http, which is easy and you can try out some initial ideas and gain a large community, you can then move to ipfs or other protocols without trouble. So no need to wait for the perfect protocol.

(d) consensus protocols base on the above.

   This is actually where I think the research is. 

The rest of the stack can be thought of as already being quasi standardised if you look at it with my RDF lenses as pointed out in (a), (b), and (c) above.

Henry

PS.  Melvin has published an intial blockchain ontology https://w3id.org/cc <https://w3id.org/cc> . Ontologies are harder to develop
though than people think, and one person's work is usually the beginning and not the end of the story, as it is ontologies are about building communities, and so sharing agreeements.
Received on Thursday, 18 February 2016 07:48:42 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 18 February 2016 07:48:43 UTC