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

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