Some issues on persistence of preservation

From the Architecture of the World Wide Web (
https://www.w3.org/TR/webarch/#URI-persistence ):

"URI persistence is a matter of policy and commitment on the part of the
URI owner."


Hi all,

I'd like to bring up some challenges in the Solid ecosystem which can
make use of our collective experience and shared values. Here are some
areas where we can use more input towards the progression of Solid
specifications:

Much has been experienced and studied on the subject of persistence and
preservation of URIs (
https://csarven.ca/linked-research-decentralised-web#persistence-and-preservation
), so I'll refrain from diving into the details on the mailing list, and
invite all to engage through primary channels (
https://www.w3.org/community/solid/wiki/ ).

The issues below are just a few. Please create new issues as you see fit.

Within the context of the Solid ecosystem - some emphasis on HTTP URIs -
we need to be mindful of the technical affordances of URIs and social
contracts.

Guidelines for publishing, discovering and using URI Persistence policies:
https://github.com/solid/specification/issues/206

We need to factor in the mechanisms to use versioned resources; their
discovery and use, as well as the promises from resource owners about
resource states and changes:

Creation of Memento resources:
https://github.com/solid/specification/issues/61

On a related note, how do we factor in provenance records and archiving?

Every so often we need to move data from one location to another. How
can servers and applications help with data provisioning, pod migrations..?

Specify mechanism for data portability:
https://github.com/solid/specification/issues/88

On a related note, how do we address data privacy and protection? Data
encryption, signatures...

That's just at the tip of the iceberg. We need to incorporate existing
work, specifications, implementation experience where possible - as
opposed to only proposing specs from scratch.

Please dive in!

-Sarven
https://csarven.ca/#i

Received on Thursday, 15 October 2020 09:52:14 UTC