[Crm-sig] Fixity Hash in CRM Addendum

Conal Tuohy conal.tuohy at gmail.com
Fri Sep 11 07:20:49 EEST 2015

This might also be a good time to dip into FRBRoo.

On 11 September 2015 at 13:14, daniel riley <daniel at verisart.com> wrote:

> Hello folks,
> I'm adding a bit to this question since I think its relevant to anyone in
> digital preservation. If anyone finds it off-topic, let me know.
> So, where we left off was that perhaps E38_Image wasn't the best entity to
> express a digital image of an artwork since E38_Image doesn't specify a
> concrete manifestation of that image.  However, in the scope notes for
> P138_represents, it explicitly states:
> "This property is also used for the relationship between an original and
> a digitisation of the original by the use of techniques such as digital
> photography, flatbed or infrared scanning."
> So it seems like the property is correct for specifying a digital version
> of the work but perhaps the Range entity is incorrect. Should I simply be
> using the superclass E73_Information_Object rather than E38_Image as the
> range, if I want to specify a digital image file with a specific set of
> bytes?
> Thanks,
> Daniel Riley
> On Wed, Sep 9, 2015 at 6:07 PM, daniel riley <daniel at verisart.com> wrote:
>> Hi Simon,
>> That makes sense. For instance, one image could have multiple sizes. We
>> would think about them as the same image but their hashes would be
>> completely different.  I am not as familiar with FRBRoo, but I took a look
>> at F4 Manifestation Singleton, and I'm not sure if its intention is
>> something like this.
>> One thing that is confusing is that in many cases like in the british
>> museum example here:
>> http://collection.britishmuseum.org/resource?uri=http%3A%2F%2Fwww.britishmuseum.org%2Fcollectionimages%2FAN00037%2FAN00037369_001_l.jpg
>> The resource is a specific digital version of an image with a specific
>> asset id and a specific filename. So it would seem that if I added a
>> property about that resource it would be about the specific binary data,
>> and not about all possible versions of that image.
>> If anyone knows of an example implementation that addresses fixity it
>> would be a great help.
>> Thanks,
>> Dan
>> P.S. I was using British Museum's linked data as a guide for most of my
>> work:
>> On Wed, Sep 9, 2015 at 5:23 PM, Simon Spero <sesuncedu at gmail.com> wrote:
>>> Another problem with this is that a hash of a bit string does not
>>> identify an Image (even if the hash is 1:1).
>>> An Image is abstract and conceptual,  and has an identity is preserved
>>> across transformations that would generate different bit strings.
>>> Going the other way,  I believe that CIDOC does require that the same
>>> bit string not correspond to multiple images. For example, an imaging
>>> sensor might capture an image with the shutter closed at the start of a
>>> series of measurements - such an image could be used for calibration.
>>> Many such images might have identical bit strings, but would be
>>> conceptually different works under some stances. However,  since they have
>>> indistinguishable appearances, they are the same Image.
>>> Fixity hashes might be better treated as properties of a FRBRoo
>>> Manifestation; such properties are intrinsic to the Manifestation*; they
>>> are not externally assigned in the same way that a URI, accession number,
>>> etc are.
>>> Simon
>>> * or as a the value of a property that must be  the same for every item
>>> that is an instance of that Manifestation
>>> On Sep 9, 2015 4:15 PM, "daniel riley" <daniel at verisart.com> wrote:
>>>> Hello all,
>>>> I wanted to get confirmation on the correct application of the
>>>> Cidoc-crm in the case of checksum hashes (i.e. fixity values).
>>>> For instance if the hash of a digital image file computes to:
>>>> 6b8dca09e851a987050463c9c60603e9ad797ba09117056fc2e0c07bcac66e43
>>>> My first thought would be to use:
>>>> E38_Image - P1_is_identified_by - E42_Identifier (hash value)
>>>> E42_Identifier - P2_has_type - "SHA256 HASH"
>>>> However, the scope notes for E42_Identifier explicitly states:
>>>> The class E42 Identifier is not normally used for machine-generated
>>>> identifiers
>>>> A hash is definitely machine generated, so what are the other options
>>>> here? Should I use a different ontology for this case?
>>>> Thanks,
>>>> Daniel Riley
>>>> Verisart
>>>> _______________________________________________
>>>> Crm-sig mailing list
>>>> Crm-sig at ics.forth.gr
>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Conal Tuohy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20150911/6667b602/attachment-0001.html>

More information about the Crm-sig mailing list