[Crm-sig] Fixity Hash in CRM
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
Re: [Crm-sig] How to represent the textual content of documents about museum objects?
I don't think that many Linked Data clients will be set up to work with XML literals. I would go for a simple wrapper to create a well formed document. RDF is not at its best when dealing with string values - witness all definitions in dbpedia and SKOS resources, which ought to have structure but can't. Richard Richard Light Sent from my phone - Reply message - From: "Conal Tuohy" To: "Richard Light" Cc: "CRM SIG" Subject: [Crm-sig] How to represent the textual content of documents about museum objects? Date: Wed, Sep 9, 2015 05:53 On 8 September 2015 at 19:05, Richard Light wrote: Your approach seems perfectly reasonable to me, in the context of an RDF/XML serialization. Presumably it might present problems in other serializations, e.g. Turtle, when you get to the point of offering more. Thanks Richard! I hadn't even considered the possibility that the XML literal might be a problem in other RDF serializations. I will look into that. Another way of doing it might be to treat the article as a free-standing information resource, mint a URL for it, and create RDF metadata which describes this resource. Your proxy software would have to resolve the URL and serve up the HTML when requested, but I assume that wouldn't be hard. Yes that is the other option I considered, and as you say, it would not be hard. In the JSON which the Museum API provides these HTML fragments are not even complete HTML documents; or even well-formed documents; they are just a sequence of elements. I think any real user interface would want to integrate them into a larger page, with a title, images, etc; that's at least partly why I chose to encode them just as literal fragments, rather than to promote them into being resources in their own right. But it's difficult to get a picture of which might actually be a useful approach for a Linked Data client. -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297
Re: [Crm-sig] How to represent the textual content of documents about museum objects?
On 8 September 2015 at 19:05, Richard Light wrote: > Your approach seems perfectly reasonable to me, in the context of an > RDF/XML serialization. Presumably it might present problems in other > serializations, e.g. Turtle, when you get to the point of offering more. > Thanks Richard! I hadn't even considered the possibility that the XML literal might be a problem in other RDF serializations. I will look into that. > > Another way of doing it might be to treat the article as a free-standing > information resource, mint a URL for it, and create RDF metadata which > describes this resource. Your proxy software would have to resolve the URL > and serve up the HTML when requested, but I assume that wouldn't be hard. > Yes that is the other option I considered, and as you say, it would not be hard. In the JSON which the Museum API provides these HTML fragments are not even complete HTML documents; or even well-formed documents; they are just a sequence of elements. I think any real user interface would want to integrate them into a larger page, with a title, images, etc; that's at least partly why I chose to encode them just as literal fragments, rather than to promote them into being resources in their own right. But it's difficult to get a picture of which might actually be a useful approach for a Linked Data client. -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297
