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

On 18 February 2016 at 08:48, Henry Story <henry.story@bblfish.net> wrote:

>
> 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 )
>

+1


> b. some way of signing that encoding
>

+0 for me this is a "nice to have", and depends on the trust profile


> c. some way of distributing the data
>

+1


> d. a consensus protocol
>

+1


>
> 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/ ). 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/
>

+1 an ideal fit


>
>
> (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/
>   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.
>

Seems to be close match, yes


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

Yes, but I would suggest building around HTTP as a base.


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

It's a good research topic and there are many ways.  I'd like to see a
pluggable architecture here, with dependency try, a bit like npm.  That's
what I am working towards with quantum payments, and I have a module to
support ILP, too.


>
> Henry
>
> PS.  Melvin has published an intial blockchain ontology
> 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.
>

It does the base chain pretty well IMHO, ive tested it by mining actual
blocks with hardware miners, and it works.  I havent done the P2P stuff but
I'd probably use bitcore for this:

https://bitcore.io/api/p2p

Webizing bitcore would be a nice student project.  I may do it if i have
time.