This might also be a good time to dip into FRBRoo. On 11 September 2015 at 13:14, daniel riley <[email protected]> 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 <[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 >>>> >>>> >> > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297
