-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Branch: Digital Image File #23
Comments
Features needed:
Then all of the core branches such as label, Name, Description, Identifier, Type, as needed. CRMDig, as discussed, is mostly about the "steps and methods of production" of the file, not the file itself. We also use dcterms:conformsTo when the image conforms to some standard, such as being a IIIF image service. |
|
Yeah, IANA media types (colloquially MIME types) aren't URIs.
|
@adamlodge The format string seems like the string enumeration datatype that you mentioned at the first face to face? Would be good to create a dropdown of the different image format media types to associate with this, rather than make people type in "image/png" or "image/jpeg"! |
Use cases for description pattern:
Further expanded models:
|
Consider IANA media types as RDM or string enumeration: |
Ok, so here's my counter proposition. I think that what is of interest about the digital image is that it's a digital image and not the image itself (the content), so I would really argue for using CRMdig so that one can reference the digital object. Eventually, one would want to find all things that are digital objects via one class and not have to know that some visual images are also actually digital images. (e.g. query returns all pdfs, images, word docs, excel files and so on via the D1 class not D1 and or E36). I agree about all the basic modelling steps that we have concluded are fundamental (name, type etc.) What about taking this as an opportunity to improve CRMdig? If we go that way, we could make a subclass for digital image objects that was subclass of D1/E36 (thus getting our representation property back). We could also start addressing the questions of format that you rightly raise above. It is missing from CRMdig and should obviously be there (as property of D1). dc:format though, I would argue is poorly formulated. The term is fine, but if you read the definition it ends up in exactly the problem we encountered in the call, by format we want to say mime type not the type of the physical thing or its dimensions (e.g. not 35mm, no digital image is 35mm by definition). I also agree with the need for the conform to property, but could you explain the meaning of it some more? Does it mean something like 'susceptible of being processed/loaded by'? If it did then what is the range of this property? A type of service? A particular service? A software? I put the partially complete counterproposal in the google sheet. If we go in this direction, I think we need to propose a new digital image class under D1 and come up with two new properties for crmdig proper that allow expressing the missing concepts of format and conforms to but with tighter semantics to avoid confusion. |
Steps to completion (updated):
The text was updated successfully, but these errors were encountered: