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

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

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 18 Feb 2016 08:16:32 +0000
Message-Id: <73D29A59-D8B2-45AB-B00C-C4769761DED6@bblfish.net>
To: Changhwan Lee <ckdghks1@gmail.com>

> On 18 Feb 2016, at 07:54, Changhwan Lee <ckdghks1@gmail.com <mailto:ckdghks1@gmail.com>> wrote:
> 
> You mean ILP have to use stellar distribute ledger as well as ripple distribute ledger?

You can always consider any kind of data structure as being mappable to RDF since mathematically
all data can be mapped to graphs of relations.  

Here is from Bertrand Russell's Principia Mathematica (first edition 1910)



So one could already map the different existing ledgers into RDF, which would be a good exercise to work out what they have in common as far as data is concerned. The RDF community has done work like that for mapping for example SQL databases to RDF https://www.w3.org/wiki/RdfAndSql <https://www.w3.org/wiki/RdfAndSql> and there are standards too
https://www.w3.org/TR/rdb-direct-mapping/ <https://www.w3.org/TR/rdb-direct-mapping/> . Clearly the data structures used by current blockchains are much simpler, so nothing as elaborate as that would be required.

From this work what one really wants is to start documenting the core concepts of those ledgers, and then see if one could implement the whole thing in RDF as an exercise. Do distributed ledgers require an DHT type protocol, then why not try IPFS as an experiment? Can one offload a lot of information behind HTTP? Then perhaps LDP will do https://www.w3.org/TR/ldp/ <https://www.w3.org/TR/ldp/> )...

One could document the required ontological differences that different consensus protocols (CP) require. ( ie what kind of relation does CP x require that perhaps CP y does not need).

> Is it possible to use the two ledgers simultaneously for ILP?
> 

I don't know.

But once you think of Ledgers as data that can interlink, then what does it mean to have 2 ledgers?
Probably no more than that 2 parts that cannot come to a consensus...

Henry

> 
> 2016년 2월 18일 목요일, Henry Story<henry.story@bblfish.net <mailto:henry.story@bblfish.net>>님이 작성한 메시지:
> 
>> On 18 Feb 2016, at 07:16, Adrian Hope-Bailie <adrian@hopebailie.com <javascript:_e(%7B%7D,'cvml','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 08:43:22 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 18 February 2016 08:43:23 UTC