- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 18 May 2021 10:44:18 -0400
- To: public-rww@w3.org
- Message-ID: <36bf7381-8725-7014-94b7-9a161a0a9d40@openlinksw.com>
On 5/18/21 6:39 AM, Melvin Carvalho wrote:
>
>
> On Tue, 18 May 2021 at 03:26, Kingsley Idehen <kidehen@openlinksw.com
> <mailto:kidehen@openlinksw.com>> wrote:
>
> On 5/17/21 4:59 PM, Nathan Rixham wrote:
>> On Mon, May 17, 2021 at 8:52 PM Henry Story
>> <henry.story@bblfish.net <mailto:henry.story@bblfish.net>> wrote:
>>
>> > On 17. May 2021, at 20:53, Melvin Carvalho
>> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>>
>> wrote:
>> > On Mon, 17 May 2021 at 19:50, Henry Story
>> <henry.story@bblfish.net <mailto:henry.story@bblfish.net>> wrote:
>> > > On 17. May 2021, at 03:33, Nathan Rixham
>> <nathan@webr3.org <mailto:nathan@webr3.org>> wrote:
>> > >
>> > >
>> > > A loosely coupled immutable timestamped record of state
>> changes allows deployment of resources to be broadly tech and
>> protocol agnostic. For example several previous states of a
>> document could be stored on IPFS, with the stateless protocol
>> HTTP providing the most recent state, and a chain exposing
>> timestamped pointers to the previous states.
>> >
>> > You can also get quite far just by adding link between
>> version states using memento for example.
>> > I am trying that out in the new Solid Server I am putting
>> together. There are comments in the code here:
>> >
>> https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/src/main/scala/run/cosy/ldp/fs/Resource.scala#L223
>> <https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/src/main/scala/run/cosy/ldp/fs/Resource.scala#L223>
>> >
>> > Thanks Henry
>> >
>> > This looks interesting, I've had a look at the comment you
>> pointed to, and it looks interesting, tho I didnt understand
>> it fully
>> >
>> > Would it be possible to describe in a couple of sentences
>> for those that are not intimately familiar with memento
>>
>> I have not implemented memento fully myself. It builds on
>> rfc5829 and allows one to link to archives that keep
>> copies of versions, though the server can be it’s own archive
>> I believe.
>>
>> >
>> > I can imagine a work stream for a temporal web based on
>> this approach, if there's interest
>> >
>> > The thing that particularly interests me is what I'll term
>> quite vaguely, a web-scale temporal web. What I mean by this
>> is, that the timestamp operation (aka the witness operation)
>> is global scope and not local. Meaning if any one website
>> goes down, the timestamping record will still be there
>> allowing a reconstruction of the history. Providing
>> resilience. In 2021, we have specialized time stamping
>> servers (commonly referred to as pubic block chain) which can
>> provide this time travel type functions. From your comment
>> there is a time travel in memento too. In any case,
>> interested in your findings, if you'd like to share ...
>>
>> I think there is a clear need for any read-write web server
>> such as Solid to keep versioning information,
>> just to help restore versions in case a buggy hyper-App
>> writes some data. That use case does not require
>> global consensus on version states. So I think that is local
>> versioning will clearly be the first
>> priority. Trellis-LDP implements somehting like this too, so
>> I am following in the footsteps to get a
>> better understanding of it.
>>
>>
>> Agree, that's the trouble with using a stateless protocol to
>> manage state!
>>
>> Exposing version via headers is a neat solution, I guess you can
>> implement etag and if none match on write requests to avoid
>> updating a resource for which you have a stale state / which has
>> already changed without you knowing. That is probably good enough
>> for most cases.
>>
>> I guess chains come in to factor when you need reliable
>> timestamps, and a provably tamper proof immutable chain of
>> previous states.
>
>
> Yes!
>
> Throughput (and associated economics) remain challenges (as far as
> I know) since blockchains are still database management systems
> albeit a specialized variety where transaction logs are based on
> various consensus protocols.
>
>
> They are finite resources due to the highly replicated, resilient and
> fault tolerant nature
>
>
> Imagine trying to track the evolution of the description of
> various entities in DBpedia since 2007, I don't know how it
> wouldn't hit all the scalability thresholds re both throughput and
> $$$.
>
>
> Fascinating use case. Well It's fair to say we could probably track a
> single page quite well. Tracking all the pages would be quite a
> challenge, but in 10 years with 5G and 100TB of data as common, this
> may actually be within reach and affordable
>
> The question arises as to why you'd want to do such a thing.
> The answer is that an independent timestamp server allows you to
> decentralize the client server model. The read write web as it is
> today is highly reliant on client server centralization. We have not
> yet made inroads into decentralizing that model leading to most things
> on the web going through a trusted third party, tracking you, or
> trying to sell you something
*Use-Case Example*
Problem: Creator Conundurum
I *painstakingly* put together an RDF document that provides details
about the Beatles that's missing from DBpedia, Wikidata, and Musicbrainz
such as:
1. Song Instrumentalists
2. Recording Location
3. Song Producer
4. Instruments per song
5. etc..
I want to publish this to the Web, but not for $0.00 since there is a
serious opportunity cost associated with the production of the work in
question.
Challenges:
1. How do I express and assert ownership?
1. How do I track use over time and receive appropriate monetary credits?
Blockchain offers me NFTs as a potential ownership assertion mechanism.
It also offers an ability for me to track credits due over time via a
Smart Contract.
Issues with Blockchain:
1. Which of the zillion tokens + platform combos to I choose from?
2. Ultimately, do any of these actually scale to the levels required?
>
> By externalizing the time component and making the data, code, and
> deployment components commodity, or access controlled commodities, you
> can start to have a read write web of humans and agents.
This isn't an all or nothing situation i.e., we cannot look at the
notion of a RWW as not being in existence without all the pieces in
place, as we see them, based on our individual preferences and
perspectives.
I would encourage a more flexible approach based on use-cases, existing
solutions, and establishment of degrees of optimal-fit in regards to
platform independence and interoperability.
> The agents are really just a decentralization of a central server
> operating over a standards based API. The RWW standards based APIs
> exist today, but the decentralized agents to run against them, largely
> do not, meaning we fall back to the persistence of central servers, or
> ephemeral clients and agents, that my run in a browser, or as a
> process, but almost inevitably do not build up enough history to
> become useful
>
> The web, ephemeral as it is, still works incredibly well, as an
> amorphous mass (in space). The hyperlink as a super key is something
> that lives in time, and accrues reputation.
Hyperlinks functioning as Super Keys are simply pointers to an address
in a distributed computer that manifests as an Entity Relationship Graph
(Graph) comprising an ever increasing number of Networks.
Note, I make a distinction between Graph and Network in that the latter
is comprised of nodes that are connected by relationship types
(relations) that are transitive in nature. For example, the Web (*as
most experience it*) comprises documents connected by a "links_to"
relation that provides the basis for algorithms such as Google's Page
Rank etc..
> With the RWW as a driver of a state machine for the web, its not just
> about robust versioning, it's about making decentralized web scale
> agents as first class as the dominant central server model, too ...
It requires micro-agents rather than the browser monolith that currently
dominates the landscape :)
Kingsley
>
>
>
>>
>> It would be nice if various approaches worked together.
>
>
> Yes, interoperability is vital.
>
> --
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Home Page: http://www.openlinksw.com <http://www.openlinksw.com>
> Community Support: https://community.openlinksw.com <https://community.openlinksw.com>
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog <https://medium.com/openlink-software-blog>
> Virtuoso Blog: https://medium.com/virtuoso-blog <https://medium.com/virtuoso-blog>
> Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers <https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers>
>
> Personal Weblogs (Blogs):
> Medium Blog: https://medium.com/@kidehen <https://medium.com/@kidehen>
> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/ <http://www.openlinksw.com/blog/~kidehen/>
> http://kidehen.blogspot.com <http://kidehen.blogspot.com>
>
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/ <https://www.pinterest.com/kidehen/>
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen <https://www.quora.com/profile/Kingsley-Uyi-Idehen>
> Twitter: https://twitter.com/kidehen <https://twitter.com/kidehen>
> Google+: https://plus.google.com/+KingsleyIdehen/about <https://plus.google.com/+KingsleyIdehen/about>
> LinkedIn: http://www.linkedin.com/in/kidehen <http://www.linkedin.com/in/kidehen>
>
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i <http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i>
> : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this <http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this>
>
--
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 Tuesday, 18 May 2021 14:44:57 UTC