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

Thank you for the very clear explanation. This does seem like the best path
to implementation and if we find any conventions within the standards that
are easy to use, we will share them out.

The reliability of images in the IIIF context was at the end of a
conversation wondering if image recognition resources (as we have access to
a HPC cluster here) could be applied to linked open data to suggest some
sameAs relationships between images of the same manuscript leaf (or any
media file), for example. It is the case that it should be nearly unheard
of for a known resource like a repository image to change after being
referenced, so what I was imagining may be a service/convention/resource of
an annotation store, but does not belong inside the model recommendations.

Patrick Cuba
Center for Digital Humanities
Saint Louis University
314-977-4249


On Fri, Jun 20, 2014 at 1:57 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
> 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
>