Open tomcrane opened 2 years ago
This came up with a recent addition to the parser. https://github.com/IIIF-Commons/parser/pull/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.
@tomcrane I've transferred to the vault-helpers repository.
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
andtype
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 withid
andtype
if it has@id
and@type
(and as long as it doesn't already haveid
ortype
properties? This would make for simpler code, e.g.,...instead of testing for
.type
and["@type"]
all the time.