Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guidelines for publishing, discovering and using URI Persistence policies #206

Open
csarven opened this issue Oct 11, 2020 · 3 comments
Open

Comments

@csarven
Copy link
Member

csarven commented Oct 11, 2020

As per https://www.w3.org/TR/webarch/#URI-persistence

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

Going forward, it would be in the interest of Solid servers - pods - to make their URI Persistence policy available as Linked Data. Applications can discover these policies and bring them to the attention of their users eg. bringing the policy to the forefront before committing to any action, like creating a pod or any resource within, as well as automate decisions on behalf of their users' based on their preferences.

Typically they describe the following:

  • a pledge towards the longevity and accessibility of the URIs;
  • what happens to the URIs once the owner ceases to exist or owners are changed.

The Solid Ecosystem or possibly the Best Practices and Guidelines document can cover this.

Policies can be expressed in different ways to suit each site's / URI owners' pledge. Here is a famous persistence policy from W3C: https://www.w3.org/Consortium/Persistence

Another example discoverable from https://csarven.ca/ and available in RDF:

<https://csarven.ca/>
  <http://www.w3.org/2000/10/swap/pim/doc#persistencePolicy> <https://csarven.ca/about#persistence-policy> .

<https://csarven.ca/about#persistence-policy>
  <http://schema.org/name> "URI Persistence Policy"@en ;
  <http://schema.org/description> "..." .

The persistence policy resource can of course be extended in any creative and useful way eg. including relevant provenance record (perhaps with PROV-O).

@d-a-v-i--
Copy link

would this be something meant to describe a retention policy as well as availability policy? hospitals in massachusetts have a 20 year requirement (https://malegislature.gov/Laws/GeneralLaws/PartI/TitleXVI/Chapter111/Section70) while in north carolina records must be kept eleven years...unless a minor, and then until the patient is aged 30 (http://reports.oah.state.nc.us/ncac/title%2010a%20-%20health%20and%20human%20services/chapter%2013%20-%20nc%20medical%20care%20commission/subchapter%20b/10a%20ncac%2013b%20.3903.pdf). or in kansas records have to be retained for 10 years, and details of records destroyed have to be retained for 25 years. (https://www.kdheks.gov/bhfr/download/Hospital_Regualtions_Nov_2001.pdf).

@csarven csarven changed the title Guidelines for publishing and discovering URI Persistence policies Guidelines for publishing, discovering and using URI Persistence policies Oct 15, 2020
@csarven
Copy link
Member Author

csarven commented Oct 15, 2020

I'd consider both of those aspects to be relevant but to be clear, the description of the policy here was intended for the URIs themselves as opposed to the data. The URIs of the records you are referring to may indeed need to have a policy that matches the existing policies on data. However, the policies for the identifier and the data don't need to be coupled. It is possible to commit to persisting the URIs longer even if all or parts of the data is no longer available.

@csarven
Copy link
Member Author

csarven commented Nov 19, 2020

Screenshot from dokieli where resource browser (via Save As) checks to see if container has a persistencePolicy property, and if so, it links to it so that user can choose to read about the policy (clicking opens it in new tab) before committing to create a resource.

image

A typical use would be a storage resource (pim:Storage) stating its policy for the URI space but it could be any container.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants