Skip to content
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

Should Vault allow retrieval of "legacy" services by id, type? #9

Open
tomcrane opened this issue Feb 7, 2022 · 2 comments
Open

Should Vault allow retrieval of "legacy" services by id, type? #9

tomcrane opened this issue Feb 7, 2022 · 2 comments

Comments

@tomcrane
Copy link

tomcrane commented Feb 7, 2022

This is one of a few issues raised by experimenting with vault for this: https://tomcrane.github.io/scratch/cp/tree.html

vault.get({id, type}) won't recover an ImageService2 or a SearchService1 because they have @id and @type, even in the normalised P3 representation. Should Vault be forgiving and still allow you to obtain this, e.g., vault.get("id": "https://example.org/my-image-service", "type": "ImageService2") ?

Vault shouldn't attempt to "normalise" ImageService2 to 3 or anything like that - it's an external service, out of vault's normalisation remit. But you might be in a scenario where you don't know what id and type are, or don't want to have special cases in the code.

More controversial - while Vault should be able to recover a @id resource from the value of that property, or a {id,type} ref, should it extend the returned resource with id and type if it has @id and @type (and as long as it doesn't already have id or type properties? This would make for simpler code, e.g.,

const someService = vault.get(serviceId);
if(someService.type === "ImageService2"){
   // do some imagey thing
}

...instead of testing for .type and ["@type"] all the time.

@stephenwf
Copy link
Member

This came up with a recent addition to the parser. IIIF-Commons/parser#9 This PR adds better support for P2 services and custom services. They no longer automatically get updated to id/type and remain as their @id and @type variants.

I think the solution, for services specifically, should be a simple helper.

const services = createServicesHelper(vault);

services.getServices(canvas);

The fully resolved services returned from this (opinionated) helper could have both id/type and @id / @type universally, in addition to any specific parsing that may be useful that could be built over time, including other helpers.

For example, using the physical dimensions service you might have a helper like:

const size = services.getPhysicalSizeInMetric(canvas);

size.unit; // cm
size.value // 80

I don't think vault or parser should change the source data. The purpose of vault is to store a valid presentation 3 representation of any manifest or collection. Helpers have the freedom to add these quality of life additions.

@stephenwf stephenwf transferred this issue from IIIF-Commons/vault Apr 29, 2022
@stephenwf
Copy link
Member

@tomcrane I've transferred to the vault-helpers repository.

@stephenwf stephenwf transferred this issue from IIIF-Commons/vault-helpers Jan 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants