- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Fri, 20 Jun 2014 11:57:36 -0700
- To: "iiif-discuss@googlegroups.com" <iiif-discuss@googlegroups.com>
- Cc: Patrick Cuba <cubap@slu.edu>, public-openannotation <public-openannotation@w3.org>
- Message-ID: <CABevsUEPEOeGXJRq+S1v+LEcwqdoHZVV0h5K0Pvh4h2m=1WBkw@mail.gmail.com>
Hi Patrick, >From an Open Annotation perspective, you're completely free to record any additional properties and relationships of the body and target resources, including checksums. The annotation spec doesn't, and in my opinion shouldn't, make additional requirements in this regard. For example, the checksum of a semantic tag or other non information resource is a meaningless concept, so it couldn't be applied across the board even at a theoretical level. Even requiring things as useful and ubiquitous as title/label/name or license will constrain implementations and potentially limit adoption if we recommend rdfs:label, and the taret community prefers dc:title for example. There is also the oa:TimeState class which would let you record when the annotation applies to the resource. If this was added, you could potentially determine if the image had changed since that time. Adding the checksum to this resource might be the easiest, but does require always using an oa:SpecificResource. >From a more pragmatic usage in the IIIF context, where we do specify what should be recorded about the resources involved, I guess that I'd like to hear how often that actually occurs. Web pages change frequently and are often dynamically generated, but images much less so. Especially in the digitized cultural heritage context, images seem very unlikely to change but if you have examples where this isn't the case, it would be great to share them. Thanks! Rob On Fri, Jun 20, 2014 at 11:19 AM, Tom Cramer <tcramer@stanford.edu> wrote: > 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 > > > -- > -- You received this message because you are subscribed to the > IIIF-Discuss Google group. To post to this group, send email to > iiif-discuss@googlegroups.com. To unsubscribe from this group, send email > to iiif-discuss+unsubscribe@googlegroups.com. For more options, visit > this group at https://groups.google.com/d/forum/iiif-discuss?hl=en > --- > You received this message because you are subscribed to the Google Groups > "IIIF Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to iiif-discuss+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Rob Sanderson Technology Collaboration Facilitator Digital Library Systems and Services Stanford, CA 94305
Received on Friday, 20 June 2014 18:58:05 UTC