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

Re: [IIIF-Discuss] Re: Annotations which verify their content

From: Robert Sanderson <azaroth42@gmail.com>
Date: Fri, 20 Jun 2014 11:57:36 -0700
Message-ID: <CABevsUEPEOeGXJRq+S1v+LEcwqdoHZVV0h5K0Pvh4h2m=1WBkw@mail.gmail.com>
To: "iiif-discuss@googlegroups.com" <iiif-discuss@googlegroups.com>
Cc: Patrick Cuba <cubap@slu.edu>, public-openannotation <public-openannotation@w3.org>
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.



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:26 UTC