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" <[email protected]> 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 > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > >
