W3C home > Mailing lists > Public > public-openannotation@w3.org > June 2014

RE: Annotations which verify their content

From: O'Steen, Ben <Ben.O'Steen@bl.uk>
Date: Mon, 23 Jun 2014 10:01:31 +0000
To: 'Tom Cramer' <tcramer@stanford.edu>, Patrick Cuba <cubap@slu.edu>
CC: "public-openannotation@w3.org" <public-openannotation@w3.org>, "iiif-discuss@googlegroups.com" <iiif-discuss@googlegroups.com>
Message-ID: <EFF934C93968B84B9B15F52121C0103F2F819646@V8L-EXCHANGE02.ad.bl.uk>
Is etag a viable route to pass this information on? https://en.wikipedia.org/wiki/HTTP_ETag


It specifies that the etag identifier is an opaque identifier, and the standard is used for cache validation. Is this suitable for IIIF to piggyback on? For instance, IIIF specifies that the etag MUST have the md5/sha as the identifier, but the rest of the world need not care, as it would function as a regular etag anyhow. Plus, it all helps caching down the line so win-win hopefully! Aside from the time to hash the image file tho…

Ben

From: Tom Cramer [mailto:tcramer@stanford.edu]
Sent: 20 June 2014 19:19
To: Patrick Cuba
Cc: Tom Cramer; public-openannotation@w3.org; iiif-discuss@googlegroups.com
Subject: Re: Annotations which verify their content

Patrick,

I'm taking the liberty of cross-posting it to IIIF-discuss, where it will also be of interest. This is an interesting wrinkle for IIIF, and one that has not come up before to my knowledge.

- Tom


On Jun 17, 2014, at 3:10 PM, Patrick Cuba wrote:


context: OAC (and SharedCanvas and IIIF) in web applications for manuscript studies using linked open data structures.

Image checksum or signature:

In IIIF it is possible that the underlying image being served has changed since last annotated, but the URI used to request it has not changed. If offered and consumed the upon the first link up, I would love to store some checksum or signature to verify the same image is used when delivered later. While this may be resolvable by also requesting some sort of image version header, a checksum would also allow me to (possibly) discover if the same image which used to be available at one location is indeed the same as another available image (assuming something like md5 or other collision-resistant checksum).

I have not worked with crypto or verification before, but it would be nice to use a checksum like a UUID in cases that the URI does not do that. As I understand it, this would also be possible with other media, with varying degrees of error.

Would such a thing be a request header? metadata? a verification annotation? Has anyone done this? If I generate my own and store it is that good enough?

Patrick Cuba
Center for Digital Humanities
Saint Louis University





******************************************************************************************************************
Experience the British Library online at www.bl.uk<http://www.bl.uk/>
The British Library’s latest Annual Report and Accounts : www.bl.uk/aboutus/annrep/index.html<http://www.bl.uk/aboutus/annrep/index.html>
Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook<http://www.bl.uk/adoptabook>
The Library's St Pancras site is WiFi - enabled
*****************************************************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster@bl.uk<mailto:postmaster@bl.uk> : The contents of this e-mail must not be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author.
*****************************************************************************************************************
Think before you print
Received on Wednesday, 25 June 2014 13:59:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:06 UTC