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

Feature Request: Show Memento Count for a URI-R #1

Open
machawk1 opened this issue Mar 19, 2019 · 4 comments
Open

Feature Request: Show Memento Count for a URI-R #1

machawk1 opened this issue Mar 19, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@machawk1
Copy link

I would like to suggest adding the ability for Memento count to be queried and displayed in a spreadsheet cell for a corresponding URI-R. A rudimentary approach would be to scrape a TimeMap for something akin to /rel=".*?memento.*?"/. As mentioned on Twitter, MemGator might be of help here (even if only configured to query a single archive), as it exposes an HTTP response header with this value:

$ memgator server &
$ $ curl -I localhost:1208/timemap/link/http://www.bl.uk
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Link, Location, X-Memento-Count, X-Generator
Content-Type: application/link-format
X-Generator: MemGator:1.0-rc7
X-Memento-Count: 14088
Date: Tue, 19 Mar 2019 15:20:43 GMT

As an extended request, abstracting the "count" value (which can be problematic) to be capable of querying other facets of the mementos in the archive (e.g., how many are 200s or redirects) would make this project's novel use of spreadsheets even more useful for cases beyond its current capability.

Potential JS implementation source to adapt: https://github.com/jarofghosts/memento-client

@ibnesayeed
Copy link

When implemented, oduwsdl/MemGator#97 will be very helpful for features like this. However, the current state of this repo's code seems very simple and does not have a lot of custom processing in it.

@anjackson
Copy link
Contributor

Can I clarify what the user need is? This add-on was initially created to answer a specific question that our curators needed to be able to ask: "Is this URL in that particular web archive?" They need to know this so they can make decisions about whether to add it to the UKWA collection.

Do we have people that need to know the global Memento count for a given URL?

@anjackson anjackson added the enhancement New feature or request label Mar 19, 2019
@ibnesayeed
Copy link

I think the tool is good enough the way it is for the purpose it is built in mind with. That said, if more than one archives are being queried then it becomes an obvious thing to utilize Memento Aggregators to both utilize the work already done for web archives to inter-operate and embrace it further. Perhaps that's why we tend to suggest such whenever there is an opportunity, even before understanding the purpose and scope of a tool fully. Though, I feel that once the TimeMap Summary feature (described in oduwsdl/MemGator#97) is implemented, tools like these can benefit a lot as it can help curators quickly identify which archives have how many copies of the URI in question, time of the last captures in each archive, and temporal activity etc.

@anjackson
Copy link
Contributor

Let me put this another way...

Adding full Memento API support and the ability to query the aggregator adds a LOT of new possibilities. But this is much more complex data with at least two axes (time v. archive), and all I've done so far is full a single cell with a single number.

So, what is the most useful thing we could do using this rich data source, and how would it work? Who would use it and what would they use it for?

(I've already had curators who want to be able to retrieve the date of the most recent copy held by us, for example, but I don't really need to use the full Memento API or the aggregator for that)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants