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

Add a before-sunset link relation type #106

Closed
ibnesayeed opened this Issue Oct 26, 2018 · 9 comments

Comments

Projects
None yet
3 participants
@ibnesayeed

ibnesayeed commented Oct 26, 2018

While the sunset link relation type allows us to convey what would be the upcoming URI of the current resource (or the resource explicitly provided as the context using the anchor attribute), there is no way to establish a backlink. A way to advertise URIs where the resources was made available earlier would be helpful in fixing search and archival indexes and bookmarks after the migration is over and previous URI is not resolvable anymore. I propose before-sunset link relation with sunset-datetime attribute, but we can discuss better names. While there is a potential of misuse by maliciously claiming someone else's resources belonged to us in the past, it is not a big issue as it is suggestive in nature and not necessarily enforced in anyway. However, in situations where the relationship can be verified bidirectionally (with the help of a Memento RFC7089), it becomes trustworthy claim.

For example, when a resource is accessed at a new URI at https://example.com/foo after DATE1, acknowledging that the resource used to be available at https://example.org/bar before DATE1:

> GET https://example.com/foo

< Link: <https://example.org/bar>; rel="before-sunset"; sunset-datetime="DATE1"

Alternatively, a more flexible method would be to define a couple of attributes (e.g., sunset-datetime and sunrise-datetime) in the before-sunset link relation type to convey time ranges when the resource was available on a different URI. Here is an examples:

When accessing https://example.com/foo after DATE1, acknowledging that the resource used to be available at https://example.org/bar before DATE1 and at https://example.net/baz between DATE2 and DATE3 (here DATE1 being the latest and DATE3 being the earliest in the past):

> GET https://example.com/foo

< Link: <https://example.org/bar>; rel="before-sunset"; sunset-datetime="DATE1"; sunrise-datetime="DATE2", <https://example.net/baz>; rel="before-sunset"; sunset-datetime="DATE2"; sunrise-datetime="DATE3"

Noting that these two datetime fields will be optional.

I find Sunset header (and the corresponding link relation type) to be very attractive and interesting for the Web Archiving community in more than one ways as I tweeted earlier https://twitter.com/ibnesayeed/status/1019744272826929155.

@dret dret added the sunset-header label Oct 27, 2018

@dret

This comment has been minimized.

Owner

dret commented Oct 28, 2018

@dret

This comment has been minimized.

Owner

dret commented Nov 15, 2018

getting close to closing this in favor of getting the RFC published without additional complications. anybody objecting make concrete suggestions now, or forever stay silent!

@ibnesayeed

This comment has been minimized.

ibnesayeed commented Nov 15, 2018

Sorry @dret, I somehow missed the email notification when you replied earlier. In favor of keeping this draft simple and limited in scope I would go with your points. I will give some more thoughts on how to expand on the foundation of the sunset to communicate historical URI versions of a resource in a separate draft. I can already see some interesting use cases in the web archiving community.

@dret

This comment has been minimized.

Owner

dret commented Nov 15, 2018

@dret dret closed this Nov 15, 2018

@ibnesayeed

This comment has been minimized.

ibnesayeed commented Nov 15, 2018

I had a brief conversation with @phonedude about it a couple weeks ago, but didn't get a chance to discuss it with @hvdsomp yet. Memento framework provided a way to link past versions of a resource as long as they have the same original URI (or URI-R), but often times those URI-Rs change (beyond URI canonicalization scope) and leave no easy way to trace back. I think @martinklein0815 will also be interested in formalizing a way to establish historical version association among multiple different URI-Rs.

@dret

This comment has been minimized.

Owner

dret commented Nov 16, 2018

@hvdsomp

This comment has been minimized.

Collaborator

hvdsomp commented Nov 16, 2018

I think @ibnesayeed makes an interesting point. He is in effect suggesting a way to express provenance of a resource, i.e. if a resource known to be accessible at URI-A at one point moves to URI-B, then URI-B could express that it used to be known as URI-A. The intended semantic is "previously known as" and it seems that it is the inverse relationship as "sunset": URI-A points with a "sunset" rel to URI-B to give a heads up that it is about to change URI. And once changed, URI-B points with a "previously known as" rel to URI-A. Seems to me that both rels could logically fit in a same I-D/RFC.

Note that the intended "previously known as" rel is different than the "original" rel from the Memento framework because original points from a version resource (in web archive or version control system) to the time generic resource. It is a relation that plays in time domain. The "previously known as" rel plays in the location/identification domain.

@dret

This comment has been minimized.

Owner

dret commented Nov 16, 2018

@ibnesayeed

This comment has been minimized.

ibnesayeed commented Nov 16, 2018

the sunset link relation does not link to a new version of the resource.
it links "to a resource providing information about a resource's or
service's retirement policy and/or information."

Thanks for pointing this out. I think my own suggestion was echoing in my head.

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