The various APIs will frequently refer to each other, as seen with the Presentation and Image API contexts. To avoid embedding references to contexts everywhere, JSON-LD 1.1 lets us use scoped contexts at these transition points. The Auth API is in the same position of being referenced from service within the Presentation and Image APIs.
Does not need to have the embedded @context, as Image3 already knows about Auth1 and can be made to know about Auth2.
However, it seems like there could be a common baseline for service (and, id, type and label whereby they're updated once, rather than everywhere? Along with a common annex document for things like section 4 of the Presentation API v3?
The various APIs will frequently refer to each other, as seen with the Presentation and Image API contexts. To avoid embedding references to contexts everywhere, JSON-LD 1.1 lets us use scoped contexts at these transition points. The Auth API is in the same position of being referenced from
service
within the Presentation and Image APIs.e.g. in Auth2, the equivalent example for https://iiif.io/api/auth/1.0/#example-description-resource-with-authentication-services
Does not need to have the embedded @context, as Image3 already knows about Auth1 and can be made to know about Auth2.
However, it seems like there could be a common baseline for
service
(and,id
,type
andlabel
whereby they're updated once, rather than everywhere? Along with a common annex document for things like section 4 of the Presentation API v3?