URL patterns for libraries

[aaccomazzi]

I will try to make this not too long, but basically I will advocate for using opaque URIs for identifying libraries in our system, as opposed to creating URIs which have semantics associated with their syntax. The main reason behind the opaque approach is one that favors persistence over readability and which frees us from making assumptions that may one day paint us in a corner. As an example, we have already seen the case where a change in the name of a library becomes impossible without URL breakage.

If we use the "semantic url" approach we would want to create URIs which encode (one or more of the following):

• user email (email) - this is not resilient against changes of email addresses
• user id (uid) - this is not resilient against deletion of accounts
• library name (libname) - this is not resilient against changes in a library's name

These disadvantages become clearer once we consider our use cases:

• user creates a library and then shares it publicly. If the user's email is exposed in the url, he/she becomes a target for spam.
• user creates a library and shares it. If the user's email changes, the old url breaks.
• user creates a library and shares it. If the user account is deleted, the url breaks.
• user creates a library and bookmarks it. If the name of the library is in the bookmark and it changes, the url breaks

What colors this discussion is my personal view that libraries should be long-lived collections, which survive the "passing" of a user, just like a google doc can have ownership transferred. This may not be a relevant issue for the current use of the libraries, but it is my hope that this will change, with the introduction of ORCID-based claims (where people will maintain their bibliography online) and crowd-sourced collections by librarians.

Down the line, we can also implement something which provides better exposure of some URLs in programmatic ways, provided that the user has chosen to make them public. For instance, we can envision creating pages such as: https://ui.adsabs.harvard.edu/orcid/0000-0002-4110-3511/works which reflect the content of a special private library called "My Papers" and which is exposed through the user's ORCID id with the user consent.

[jonnybazookatone]

So I've started a document within the issues under microservices to sumarise all of this. I'll update it once I've gone through your points.

[jonnybazookatone]

From what you wrote I interpret the following:

Specification:

1. URIs should not contain sensitive information.
2. The user should not have to manage their accounts, like in GitHub. If they make a resource, the link to the resource should remain permanent, regardless of meta-changes to the library itself, or the user account it is associated with.
3. A user loses the ability to remove library content by deleting their account, once it is shared with someone (see below).

One question for the third point in the specification (or clarification on your comment). You said:

"user creates a library and shares it. If the user account is deleted, the url breaks."

What is the requirement for this behaviour - this defines the specification? If I created a library that was shared and then I deleted my account, I would expect that any content I owned and shared should also be deleted, unless I explicitly give someone else ownership.

I would expect the same behaviour if I was to delete my library, I would not care if I had shared the content, even given people administrative abilities (r+w), if I owned it and deleted it, it would be gone.

[jonnybazookatone]

Even though I advocated 1 admin during the meeting. I am 50/50 on the idea of more than one admin. I would still foresee having the owner of the library who can delete the library if they wish. The admin would be able to read/write any permissions settings and read/write the library content. The admin would not be able to change the permissions of the owner. This is perfectly feasible in the current data model.

[jonnybazookatone]

So, to clarify my statement, it would imply the following permissions:

1. Owner: can delete library, pass on ownership, add admins, add editors
2. Admin: can add/remove editors, have same privileges as editors, cannot read/write to owner
3. Editor: read/write privileges to libraries

[aaccomazzi]

Good question:

If I created a library that was shared and then I deleted my account, I would expect that any content I owned and shared should also be deleted, unless I explicitly give someone else ownership.

In the "Rahul model" of ADSGUT, groups were explicitly created for this purpose: a group would own a library, and removal of members, accounts from the group did not kill the group (and library). With the new redesign, I think it's best to stick to the "google docs" model, which has roles for owners, editors, and viewers. Here is how they are defined: https://support.google.com/docs/answer/2494886?hl=en

So I agree with the roles you define, which are basically the same ones in google docs (with the exception that the "admin" role is rolled into the editor role). There is one and only one owner and he/she is the only one who can transfer ownership to somebody else. The last role not included in your list is:

1. Viewer: can read contents of libraries

And of course we need to support the case where the viewer role is set to "everybody," whether they have or not an ADS account.

[jonnybazookatone]

Yes, I left that off by mistake. So the updated list would be:

1. Owner: can delete library, pass on ownership, add admins, add editors
2. Admin: can add/remove editors, have same privileges as editors, cannot read/write to owner
3. Editor: read/write privileges to libraries
4. Viewer: can read the library

There is a public/private option also rolled in to the library itself, which would apply for ADS users that do not have an ADS account.

I'll close this now. Feel free to re-open it if you change your mind.

[jonnybazookatone]

I may have closed it prematurely, given the title is about URL end points too.

They would take the form, as e.g.:

libraries/uuid share/uuid

This is:

• permanent to changes in library name, ownership
• defunct if the owner deletes their account
• opaque:
  • not automatically crawlable by bots
  • does not make visible any confidential information

This requires that the header passes on information such as the requesting user (e-mail or uid), and e.g., the user to be modified.

Again, re-open if there are any disagreements.