You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
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.The text was updated successfully, but these errors were encountered: