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

Patrick,

I recently read this paper, "Trusty URIs: Verifiable, Immutable, and
Permanent Digital Artifacts for Linked Data":

http://arxiv.org/abs/1401.5775
see also: https://github.com/trustyuri

I found it helpful, and perhaps it's relatable to your needs.




On Fri, Jun 20, 2014 at 1:19 PM, Patrick Cuba <cubap@slu.edu> wrote:

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


-- 
Tod Robbins
Digital Asset Manager, MLIS
todrobbins.com | @todrobbins <http://www.twitter.com/#!/todrobbins>