Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a separate solution to explore how an incoming manifest is mapped to the canvas_paintings table.
See output:
https://github.com/dlcs/iiif-presentation/blob/c5e2bb18233a6758af5b9d8485611517c2b65b37/src/CanvasPaintings/Demo/output.md
This .sln references iiif-net but I have temporarily got it running by referencing the project locally rather than on nuget, as there is a PR required to fix some deserialisation issues getting it to work with all the IIIF Cookbook recipes.
digirati-co-uk/iiif-net#51
There's a class library, Mapper, that has a fake EF Entity class for the table row:
https://github.com/dlcs/iiif-presentation/pull/93/files#diff-198ae948819d1eb1dff4b174f9899730120c80bcac893af66b0cd57bcd1a903a
Then there's a Demo that exercises this API.
https://github.com/dlcs/iiif-presentation/pull/93/files#diff-0c4a7a8e4a274bf12a449ba681e3403020d3f24b6c4b91d6a9b69c6fe7e321e6
The code as-is will request the IIIF Cookbook collection from Stephen's Theseus viewer:
https://theseus-viewer.netlify.app/cookbook-collection.json
It adds an additional Manifest to this that has "internal" assets - i.e., we recognise then as managed by us, DLCS assets. - https://github.com/dlcs/iiif-presentation/blob/c5e2bb18233a6758af5b9d8485611517c2b65b37/src/CanvasPaintings/Demo/output.md#wunder-internal
It then produces a "table" for each Manifest; the rows that would go into our canvas_paintings db table.
I mint new Canvas IDs and Manifest IDs every time, but in practice we would obviously match rows with what we already have in the DB.
It also shows what would go in the flat, show-extras Manifest under the
paintedResources
property. I'm not sure how much to output here, and what can be left to be read from the Manifest JSON.For later
A client creating a manifest by supplying paintedResources directly could also be supplying targets. I haven't got the reverse operation here of creating the JSON from the canvas_paintings (which only happens when no JSON exists already).