This solution tightly integrates the solution for raw mementos with the existing Memento framework. Archives will need to expose the dimensions of rawness that they support so that Memento aggregators can then evaluate the mementos offered by each archive.
Because the TimeGate must redirect to a URI-M that satisfies the preferred dimensions of rawness, mementos containing different dimensions of rawness will need to be identified by different URI-Ms.
But this sounds to like it should be a pro :)
The whole point of adding this is to integrate with the Memento framework!
I imagine this working by including a Prefer: original-content to a TimeGate request, and being redirected to the id_ or im_ version of the url, instead of the rewritten version (no id or im)
Because the TimeGate must redirect to a URI-M that satisfies the preferred dimensions of rawness, mementos containing different dimensions of rawness will need to be identified by different URI-Ms.
This too sounds like it should be a pro! The TimeGate should redirect to a different URI-M if it is rendering the content differently, otherwise the same URL could represent completely different content.
If curl -H 'Prefer: screenshot' 'http://archive.example.com/web/2016/http://example.com/' returns a screenshot, while
curl -H 'Prefer: original-content' http://archive.example.com/web/2016/http://example.com/ returns HTML while curl -H 'Prefer: emulator-netscape-3' http://archive.example.com/web/2016/http://example.com/ returns an embedded emulator running Netscape 3, then then meaning of
the URL http://archive.example.com/web/2016/http://example.com/ is completely lost!
A user might send this url thinking it was a screenshot to another user, who would only see plain HTML. A user could not reliably cite this URL nor share with others, without knowing the value of a hidden Prefer header and how it completely changes what they are viewing! If there was a memento plugin that specified the Prefer header and resulted in different renderings, it would just lead to confusion.
Of course, URLs are not guaranteed to be the same in any sense to begin with, but I think this would just make archives seem less reliable indicators of content, and is against common practices of RESTful APIs.
To avoid these issues, a screenshot, raw memento, and an embedded emulator should all have unique urls, and do, in current implementations of such features.
A con for option 1 states:
But this sounds to like it should be a pro :)
The whole point of adding this is to integrate with the Memento framework!
I imagine this working by including a
Prefer: original-contentto a TimeGate request, and being redirected to theid_orim_version of the url, instead of the rewritten version (no id or im)This too sounds like it should be a pro! The TimeGate should redirect to a different URI-M if it is rendering the content differently, otherwise the same URL could represent completely different content.
If
curl -H 'Prefer: screenshot' 'http://archive.example.com/web/2016/http://example.com/'returns a screenshot, whilecurl -H 'Prefer: original-content' http://archive.example.com/web/2016/http://example.com/returns HTML whilecurl -H 'Prefer: emulator-netscape-3' http://archive.example.com/web/2016/http://example.com/returns an embedded emulator running Netscape 3, then then meaning of the URLhttp://archive.example.com/web/2016/http://example.com/is completely lost!A user might send this url thinking it was a screenshot to another user, who would only see plain HTML. A user could not reliably cite this URL nor share with others, without knowing the value of a hidden Prefer header and how it completely changes what they are viewing! If there was a memento plugin that specified the Prefer header and resulted in different renderings, it would just lead to confusion.
Of course, URLs are not guaranteed to be the same in any sense to begin with, but I think this would just make archives seem less reliable indicators of content, and is against common practices of RESTful APIs.
To avoid these issues, a screenshot, raw memento, and an embedded emulator should all have unique urls, and do, in current implementations of such features.