[Crm-sig] Fixity Hash in CRM Addendum

daniel riley daniel at verisart.com
Fri Sep 11 06:14:07 EEST 2015


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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20150910/08a5a41a/attachment.html>


More information about the Crm-sig mailing list