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

>> and a client and can communicate
>> both ways.
>
>
> Unsure I understand this.  A server is a fairly simple one-liner these
days.  But a client.  Is that curl, or a browser, or a chat bot, or another
server?

I simply mean that the application has both a built-in HTTP server and a
built-in HTTP client. That's what allows it to function as a peer in a P2P
setup:
- when sending a request it functions as a client
- when responding to a request it functions a server

>>     One of the agents accesses (dereferences) an RDF document on the
>> peer application, and stores that data in its own application.
>
>
> OK
>
>>
>>
>> And that's it, to begin with.
>
>
> I think we can do this, seems more like a bot you are describing

It can be a bot or it can be be a human agent who manages a (decentralized)
personal RDF dataspace.

> Cross reference seems a bit like validation here?  An important step, and
actually one I didnt cover originally so thanks for pointing that out.
State changes would benefit from being subject to a set of rules for valid
data

I meant being able to add new data and then query over it.

Validation is orthogonal, so best to be left out at this stage.

>> Is that too simplistic? Then please show me an RDF-based app that can
>> do this out-of-the-box.
>
>
> Does such an app exist to your knowledge?

LinkedDataHub can easily add data, but “Save As...” UI functionality is
currently missing.

Maybe Solid can do that too, not exactly sure.

> If not I think it's possible to build.  The temporal component in your
use case did not seem obvious to me

It is definitely possible to build, if we focus on the basics first and
specify them.

> So, we'd need to understand what cross referencing means
>
> Would the data store also be public or private?  e.g. something like a
file based store, or require a quad store

Public/private depends only on the authorization layer which is orthogonal.
So it could be either way.

I think file storage has severe limitations. It would rule out querying at
least.

For RDF, a triplestore is the most natural storage backend.

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