Rethink interface extension

[rettinghaus]

The current idea for specifying the access through an API is to add the constraint interface with the possible attributes "OAI-PMH" and "IIIF" and allowing them to be accessed "internal" or "external".
That would bring us more attributes, that

• would not fit nicely into our current schema (single word, lowercae)
• only allows two values, that are the same for both (basically a boolean schema)
• would leave out all other used APIs (every extra one would need a new extension)

Standard APIs in GLAM are:

• IIIF Image API
• IIIF Presentation API
• OAI-PMH
• ResourceSync
• SRU / SRW
• SPARQL

My proposal would be to name the constraint "api" and the matching attribute "apis", which can take a list of availble APIs.

I'm not sure why the "internal" and "external" would be needed, when we already restrict this already through inside, groups, subnet , etc.

So currently it would be encoded as

<restriction type="interface" OAI-PMH="internal" />
<restriction type="interface" IIIF="internal" />

With the arguments above it could be:

<restriction type="inside" location="SLUB" />
<restriction type="api" apis="IIIF OAI-PMH" />

But the basic question is if objects need to blocked completely for a single API, or are the other restrictions enough.
From my point of view the mets extension should be sufficient for provisioning through apis.

[sebastian-meyer]

I am in favor of this proposal because it brings API restrictions more in line with the way other constraints are handled in LibRML.

However, I’m not sure if we even need explicit restrictions for APIs. Wouldn’t it be better to start with the resource type and work with the existing restrictions?
Interfaces like OAI-PMH or the IIIF Presentation API provide access to the object description, so in principle they are equivalent to a download in the “METS” or “IIIF” formats (or even a more generic allow metadata download). It shouldn't matter if this download is achieved by an specific API or a simple file link. Or is there any scenario in which e. g. access via OAI-PMH is forbidden, but a download link to the METS file would be allowed?
The IIIF Image API or ResourceSync, on the other hand, provide access to the digital object itself, which can be described by using the constraints for image download (max resolution, etc.).
SRU / SRW or SPARQL are search interfaces so they should follow the same constraints defined for indexing.

In other words: Why should we distinguish between different technical ways of accessing certain parts of a digital object? Why don't we just put constraints on those parts and require presentation software to enforce those restrictions for all possible ways of access? So, e. g. if downloading high resolution images is only allowed for certain users, then this must be enforced for direct file links as well as any other interface without the need to explicitly list all of those. (Technically, a simple file link is an (HTTP) interface as well...)

[rettinghaus]

After careful consideration we decided to not implement this schema extension at all.