-
Notifications
You must be signed in to change notification settings - Fork 0
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
Multimedia #10
Comments
Each piece of media that is "published" will have its own IIIF documentation - so a *.info URL for each file and then various manifests, potentially one per file? Each image would also then have a direct URL to and actual image file/thumbnail from the IIIF server - so we will have a few URIs to chose from once we see what might work best. |
Can we create Linked Art Visual Work records from the *.info files? And, if so, how do we deduce the URIs for those records from the information in the CIIM output, so we can link to them from the object records? |
As in some of the other conversations I think it would be good to avoid deducing too much, if you need an image of each object then the raw data should probably include a full "thumbnail" url - which would then refer to the current primary image. That being said the "paths" in the media section may need to change as the discussion was for the file paths to be replaced with PIDs for the images - I can not remember where that led to. The current relative paths do not actually resolve outside the NG yet so they will need to change. What is the LA template that you want to replicate? |
Well I said Visual Work above, but on reflection and a re-reading of the spec I think it's more a question of a Digital Object (https://linked.art/api/1.0/endpoint/digital_object/). I picked up on using Visual Work because the API listing for objects has Visual Works as the target for 'representation' statements. I'm not sure how you make the link, in Linked Art, between an artwork and a digital image of that artwork: it doesn't seem to quite work in either direction. I'll ask my new friends on the Linked Art list for their thoughts on this. |
File paths will be replaced by PID-based IIIF Image API URLs for images. We should aim to link to a single image, using its PID / UID, and let the CIIM's access management decide what can be delivered. Manifest creation is still under discussion and we should probably pause on linking to manifests until we're clearer about precisely what we're doing there. |
If there is [going to be] a separate sub-system which mints URIs for each multimedia resource, then it's just a matter of transforming the manifest into a Digital Object for delivery as Linked Art JSON, and then linking to that metadata record from the Object record. |
I think we need to be clear about the distinction between image URIs and manifests. The CIIM can deliver both, and it'll be easier to implement the former in our LA JSON than the latter: we simply need to prepend the agreed image path (fixed) to the relevant multimedia entity's PID / UID. We don't yet have a system for PIDing manifests, so those need to go on hold just now. |
Still to be resolved - it'll need a discussion with Rob - whether media records should exist in their own right in the public index to support ontologies like Linked Art? |
#22 (comment): discussed with Rob; we will be doing this; but it will take a little time ... |
What's the plan for multimedia?
Linked Art assumes that each digital object will have its own URI and will be a Visual Work. This would tie in nicely with your having recorded different resolutions/formats of the 'same' image - I think we could make a perfectly respectable Visual Work record (i.e. LA JSON) out of the information you already expose.
However, you have indicated that you don't want to create new records or mint new URIs.
Unless we do make this information into a separate record, we can't use the 'representation' key to hold the references to it, since the Reference structure mandates a URI for the target of the reference. So I would have to work out an alternative property to hold this Visual Work data.
I also note that the 'location' of the actual image file is a relative path, so it is not possible to use the information provided to access the actual digital images.
The text was updated successfully, but these errors were encountered: