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

Could eTags be used for this? (https://duckduckgo.com/HTTP_ETag).

One thought comes to mind. If an anno is licensed, and then it is changed,
those who have used it in the meantime might want a record of the version
that they downloaded/used. This is not an anno-specific problem, but since
it is being designed from scratch, could we actually think through this
carefully? (Note to Patrick: thanks for bringing this up).


On Fri, Jun 20, 2014 at 8: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
>



-- 
Puneet Kishor
Manager, Science and Data Policy
Creative Commons