1.2 Access restrictions


The Goobi viewer can interpret access restrictions. For this, they must exist as metadata. The following application scenario describes how to capture and configure an access licence using a moving wall as an example.

Goobi workflow

For example, the access restriction for works whose rule protection period expires at a certain point in time can be configured in such a way that these works are only visible to certain users up to this point in time and are released to the general public from this point in time onwards. In Goobi workflow, a metadate must exist for this, in which a year has been recorded. Here is an example of the relevant sections within a rule set:

    <language name="de">Anzeige im Internet ab Jahr</language>
    <language name="en">Public release year</language>

<!-- [...] -->

<metadata num="1o" DefaultDisplay="true">PublicReleaseYear</metadata>

<!-- [...] -->

    <WriteXPath>./mods:mods/#mods:accessCondition[@type='moving wall']</WriteXPath>

Goobi viewer Indexer

This metadata must then be indexed in the Goobi viewer Indexer. Here is an example configuration:

            <xpath>mets:xmlData/mods:mods/mods:accessCondition[@type='moving wall']/@type</xpath>

            <xpath>mets:xmlData/mods:mods/mods:accessCondition[@type='moving wall'][translate(., translate(.,'0123456789',''), '')]</xpath>

It is important that both contents are indexed: the information that there is an access restriction (field ACCESSCONDITION) and the contents of the field (field DATE_PUBLICRELEASEDATE)

Goobi viewer Backend

Now the new access restriction must be configured in the Goobi viewer Core administrator backend, whose name corresponds to the value in ACCESSCONDITION. In the example above, this is moving wall.

To activate the moving wall, only the toggle must now be activated.

Last updated