Re: tracking state changes in a temporal read-write web

Hi all,

Why do these discussions immediately explode in all possible
directions? Temporal integrity, blockchain (agnostic), hashing... How
about we figure out the very *very* basics first, and start building
from that?

I have a suggestion for a simple decentralized use case:

    There are 2 agents running instances of the same application,
where the instances are peers since the application includes both a
server (with an RDF storage backend) and a client and can communicate
both ways.
    One of the agents accesses (dereferences) an RDF document on the
peer application, and stores that data in its own application.

And that's it, to begin with. The intention is that now the agent can
cross-reference the new data with the rest of the data in its
application, e.g. using SPARQL if the storage supports it.
Authentication, authorization are of course also in this picture, but
they are orthogonal, so for the sake of simplicity we can skip them
for now.

Is that too simplistic? Then please show me an RDF-based app that can
do this out-of-the-box.
After this, we can proceed to add more requirements to this scenario.

Martynas

On Fri, May 21, 2021 at 4:14 PM Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
> On 5/21/21 7:34 AM, Melvin Carvalho wrote:
>
> this is the outline of a strategy to track state changes in a temporal read-write web
>
> by no means the only strategy, but an aim to generalize some of the recent discussions
>
> 1. Data as a declarative state machine
>
> The data can be considered as a declarative state machine, offering state transitions
>
> Simple case is one document, but it's useful to have multiple documents over a set of quads (linked data) or directory tree (file system)
>
> It seems standard practice to track this data using a hash function. So the first step would be to hash the document or tree or knowledge base into a chain of hashes.  Git or other VCS systems do this, similarly with single documents you could take a sha2, for example, and maintain a chain of hashes that way
>
> 2. Bootstrapping a timestamp server to witness hashes
>
> Robust global timestamp servers have existed for over a decade, popularized by the bitcoin project, often referred to as block chains, because data is tied to those timestamps in the form of 'blocks' of data.  Users compete for space on those blocks based on an auction basis, as they are a finite resource, to make them spam resistant
>
> The chain of hashes described in (1) can be tracked on the blocks of the timestamp server, which tend to have a common transaction format.
>
> What is needed is hash1,hash2,hash3...hashn to be sequenced in time from a definitive start, or genesis.  That genesis can become an identifier for the chain of linked data which we wish to securely witness.
>
> Block chains typically follow a transaction in time from spent -> unspent.  The terminology is that of inputs and outputs.  This can be thought of as source and destination.
>
> The transactions are identified as cryptographic hashes, with an array of outputs.  In order for a timestamp server to track a chain of linked data, we need to construct a URI for the linked data hashes (hash1,2...n) and for the block chain transactions (tx1,2,...) with the first tx being a genesis identifier
>
> Gaps needed to fill:  create URIs for hash1,2,...n.  Create URIs for tx1,2...n
>
> 3. Two way links between state machines
>
> Two way links between those state machines ensure strong coupling between the two systems providing a bootstrap.  So from the case of the linked data, you need a pointer to the transaction URI.  And from the block chain you need a pointer to the hash URI.
>
> From a block chain there's a couple of ways to do this, one is the so-called OP_RETURN which allows you to embed data in at transaction.  The other is known as 'tweaking' a public key on order to add a hash (hash1,2...n in the web chain)
>
> Linking from linked data to a transaction, once you have a URI can be done in a number of ways.  But as linked data is designed to link to other URIs it's quite doable by putting it onto the data structure.  Another technique, for example in VCS is to put a link in the commit message, as commit messages are part of the chained tree
>
> 4. Ensuring Temporal Integrity
>
> Once (1), (2), (3) are in place.  Change can be made to the state machine, and new hashes generated.  With the example of git we can commit hashes to a file system, or a centralized server such as github
>
> But, If we want to commit at web scale, we can do so as follows:
>
> Firstly generate a hash of the new state.  Then move the transaction in the block chain along to point to this new state.  The transaction itself has PKI based ownership rights which have a variety of ways to manage and transfer ownership including so-called "multi sig" ownership where any N of a given M actors need to agree on a transition
>
> Finally, point the web chain back to this new transaction once it is confirmed
>
> This will progress the web chain in time and mirror it on the underlying time stamp server
>
> The resulting system creates a temporal read write web state machine anchored to the strong assurances of an underlying timestamp server
>
> This is a sketch outline of something that could be turned into a prototype or MVP, and also illustrating the gaps in technology that we need, namely to create two URI schemes, to hash web state, and describe state transitions, for data and for agents
>
> Appreciate this is a sketch outline right now, feedback welcome!
>
>
> Great explanation!
>
> Challenge:
>
> Persisting this in a form that available for easy recall.
>
> Suggestions:
>
> 1. Documentation using RDF sentences in a document
>
> 2. A visual diagram to complement -- e.g., using http://draw.io
>
> Example:
>
> 1. http://www.openlinksw.com/data/turtle/general/knowledge-graph-manifestation-turtle-jsonld.html -- I constructed that for explaining Hypertext, Hyperdata, Hypermedia etc., in relation to Knowledge Graphs; that all started from a draw.io diagram .
>
>
> --
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Home Page: http://www.openlinksw.com
> Community Support: https://community.openlinksw.com
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog
> Virtuoso Blog: https://medium.com/virtuoso-blog
> Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>
> Personal Weblogs (Blogs):
> Medium Blog: https://medium.com/@kidehen
> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
>               http://kidehen.blogspot.com
>
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
> Twitter: https://twitter.com/kidehen
> Google+: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn: http://www.linkedin.com/in/kidehen
>
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
>         : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>

Received on Friday, 21 May 2021 14:35:22 UTC