title | layout | tags | summary | |
---|---|---|---|---|
IIIF Registry |
default |
|
tbc |
This is the basis of the IIIF Registry of Activity streams. This project aims to give access to a large amount of IIIF resources and provide a way to keep up to date with changes. The Activity Streams format is defined in the Change Discovery Specification.
We welcome additions to the registry and additions can be made using the following process:
- Create branch for your addition
- Create a directory for your institution. This should be a short name without spaces or punctuation
- Create a registry JSON file. See details below
- Create a pull request with your changes and submit to IIIF/registry
To register a link to your streams we use the following JSON structure:
{
"id": "http://www.getty.edu/",
"institution": {
"id": "http://www.getty.edu/",
"label": {
"en": [ "Getty" ]
}
},
"streams": [
{
"id": "http://www.getty.edu/museum.json",
"label": {
"en": [ "Museum collections" ]
}
},
{
"id": "http://www.getty.edu/library.json",
"label": {
"en": [ "Library collections" ]
}
},
{
"id": "http://www.getty.edu/research.json",
"label": {
"en": [ "Research Center" ]
}
}
]
}
Where:
id
is a URI for your institution. This could be an institution website, Wikidata URI or other resolvable link.institution
the name of the institution that could be shown to a user. This is an optional field but encouraged.streams
list of activity streams for this institutionid
Activity Stream URL. Must be resolvablelabel
a description that can be shown to the user so they can tell which stream to monitor for updates.
The JSON file should be named appropriately so people know what it represents and must have an extension of .json
.
For Aggregators or institutions that collect content from other providers and aggregate their content. A slightly different structure can be used. Examples of Aggregators would be Europeana or OCLC with ContentDM. Both hold multiple institutions' data. In this case the Aggregator would have one registry JSON file per institutional client. The Provider can then add the following to the root of the JSON to show who provided the content:
"provider": {
"id": "https://www.oclc.org/en/home.html",
"label": {
"en": [ "OCLC" ]
}
},
You can see examples of this in the OCLC directory where instx.json would be the set of changes from one ContentDM instance and insty.json is a second institution.