Support v3 ServiceProfiles

[christopher-johnson]

In the v3 API, service profiles can be non URIs. eg. ("level2"). I started testing the UV with v3 manifests. What happens is that if a service profile is not in the predefined service enumeration, then it tries to dereference the resource id, and that does not work. I would suggest using a context to validate a service profile rather than maintaining a static list, (but the v3 context does not define them).

There could perhaps be a global registry for service providers that would be served as an independent context, or have a standard service context name for manifesto to check these profiles against.

[edsilv]

I think for now the best thing would be to add entries to https://github.com/IIIF-Commons/manifesto/blob/master/src/ServiceProfile.ts

I'd really like to change this and other enums to use TypeScript String Enums too: https://blog.mariusschulz.com/2017/10/27/typescript-2-4-string-enums

This would have pretty far-reaching side-effects in manifold and UV, but I think probably an afternoon's work updating all references.

Perhaps we could then spin these enums out into a separate reusable npm module?

[christopher-johnson]

Using String Enums and putting them in a reusable npm is a good idea. This is what I have done previously in Java with iiif.vocabulary . I guess it is also a question of confirming what the terms for all existing/new service profiles are?

[edsilv]

I've created this: https://github.com/IIIF-Commons/vocabulary

We could publish this under the @IIIF npm namespace. I think we could get the initial enums in there then talk to the software devs community about what else needs to be added?