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 <[email protected]> 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 <[email protected]> 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" <[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 >>> >>> >
