Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd a before-sunset link relation type #106
Comments
dret
added
the
sunset-header
label
Oct 27, 2018
This comment has been minimized.
This comment has been minimized.
|
On 2018-10-26 20:45, Sawood Alam wrote:
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 <https://tools.ietf.org/html/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.org/bar>; rel="before-sunset"; sunset-datetime="DATE2"; sunrise-datetime="DATE3"
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.
thanks for the feedback and the suggestions. it seems that what you are
proposing here is quite a bit more sophisticated and complex than what
the draft currently does.
the goal for this draft has been to be able to announce sunsets, and
that's really all there is to it. it seems to me that you are going deep
into the question of how to manage resources, which to me is a different
thing.
here's a suggestion: let's keep those two aspects (announcements vs
management) separate, and the current draft as simple as it is. i'd be
more than happy to help/comment/contribute to a new one that would be
based on sunset, but address the scenarios you have in mind.
i also had some ideas along the way about what could possibly be added
to the draft, but it never seemed like that was a concrete requirement
for people. in case you're interested, feel free to explore the open
issues, and you might find some ideas similar to the ones you're suggesting:
https://github.com/dret/I-D/issues?q=is%3Aissue+is%3Aopen+label%3Asunset-header
|
This comment has been minimized.
This comment has been minimized.
|
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! |
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
|
On 2018-11-15 15:15, Sawood Alam wrote:
Sorry @dret <https://github.com/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.
sounds good, and thanks for the quick response. i'll go ahead and close
the issue, then.
if you do write up something new, i'd definitely be interested to see it
and maybe to contribute. there definitely is room for more complex
models that the simple of proposed by the sunset draft. i think checking
back with @hvdsomp would be great to get his feedback and input, he is
extremely experienced in the field of archiving.
|
dret
closed this
Nov 15, 2018
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
|
On 2018-11-15 18:26, Sawood Alam wrote:
I had a brief conversation with @phonedude
<https://github.com/phonedude> about it a couple weeks ago, but didn't
get a chance to discuss it with @hvdsomp <https://github.com/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
<https://github.com/martinklein0815> will also be interested in
formalizing a way to establish historical version association among
multiple different URI-Rs.
you're right that while there is some overlap, there also may be
different scenarios at play here. memento assumes you're versioning one
resource (afaict), and how to navigate the history of various versions
that may be available. sunset assumes that a resource (versioned or not,
that's not something sunset is concerned with) goes "out of business"
and wants to announce this in advance. looking at it from that angle, it
almost seems like these things complement each other nicely, without
having much overlap at all. i am really wondering what @hvdsomp's take
on all of this is.
|
This comment has been minimized.
This comment has been minimized.
|
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. |
This comment has been minimized.
This comment has been minimized.
|
On 2018-11-16 14:50, Herbert Van de Sompel wrote:
I think @ibnesayeed <https://github.com/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.
these are interesting thoughts, but that's not how sunset is currently
defined. currently, the scenario is that a resource simply goes out of
business. it may be resurrected someplace else, but that's out of scope.
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."
i still think that this richer model of interlinking resource migrations
may be interesting, but it seems to be a rather different (and decidedly
more complex) beast. i'd be interested to have a closer look, but i
think it is different from what the current draft is targeting.
|
This comment has been minimized.
This comment has been minimized.
ibnesayeed
commented
Nov 16, 2018
Thanks for pointing this out. I think my own suggestion was echoing in my head. |
ibnesayeed commentedOct 26, 2018
•
edited
While the
sunsetlink 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 theanchorattribute), 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 proposebefore-sunsetlink relation withsunset-datetimeattribute, 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/fooafterDATE1, acknowledging that the resource used to be available athttps://example.org/barbeforeDATE1:Alternatively, a more flexible method would be to define a couple of attributes (e.g.,
sunset-datetimeandsunrise-datetime) in thebefore-sunsetlink relation type to convey time ranges when the resource was available on a different URI. Here is an examples:When accessing
https://example.com/fooafterDATE1, acknowledging that the resource used to be available athttps://example.org/barbeforeDATE1and athttps://example.net/bazbetweenDATE2andDATE3(hereDATE1being the latest andDATE3being the earliest in the past):Noting that these two datetime fields will be optional.
I find
Sunsetheader (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.