Diverse Applications of Linked Data Notifications for IIIF Resources

Jeffrey C. Witt (Loyola University Maryland)

Patrick Cuba (St. Louis University)

LDN Goals and Motivation

The Goal of using Linked Data Notifications with IIIF is to connect “Supplemental Information” from third parties with institutional manifests.

When institutions make their images available, scholars and researchers use them, study them, and create new data.

How can institutions receive this supplemental information back to enrich the viewing experience of their own collections

How do we complete the circle, so that open data sharing is a

“rising tide that lifts ALL boats”?

Typical LDN / IIIF pattern

• Sending a Notification
1. Dereference a manifest
2. Look for an inbox location in the service block
3. Send notification to inbox location
• Receiving notification
• Manifest is provided
• Client looks for inbox location in service block
• Client retrieves notifications from inbox

1. Manifests need to declare inbox location. No one wants to modify manifests.
2. Manifests need to point to inboxes. No one wants to set them up.
3. Information from Inbox needs to be harvested and then the manifest must be further modified. No one wants to do this!

​

Problems

IIIF and LDN: History, Lessons Learned, and Solutions Proposed

• 2016, Rafael Schwemmer and Jeff Witt demonstrate sharing using WebMentions.
• Required institutional inbox and required heavy modification of institutional manifest.
• 2017, Chip Goines and Jeff Witt demonstrate sharing using Linked Data Notifications.
• Still requires institutional inbox and required modification of institutional manifest.
• 2018
• We recognized that there was interest, but the burden for implementation was simply too high.
• So we lowered the bar.
• A regional, 3rd party inbox
• A web form for sending notifications
• A client side retrieval of notifications eliminating the need for manifest modifications
• Enabled retrieval not only of Ranges, but AnnotationLists and Layers

​

Solution: Regional Inboxes; enter Rerum Inbox

"service": {� "@context": "http://www.w3.org/ns/ldp#inbox",� "@id":"http://inbox.rerum.io/messages� ?target=http://example.com/book1/manifest.json",� "inbox":"http://inbox.rerum.io/messages� ?target=http://example.com/book1/manifest.json"� "profile": "http://www.w3.org/ns/ldp#inbox",� "label": "Linked Data Notifications inbox"�}

Regional Inboxes can be pre-known by clients, so even if a manifest does not declare an inbox, a client can check known regional inboxes.

Solution: Client Side Inbox Retrieval and Manifest Modification

Example

Send a notification

Inbox Receives Notification

Sample Inbox: http://inbox.rerum.io/messages?target=https://scta.info/iiif/plaoulcommentary/sorb/manifest

{

"@context": "http://www.w3.org/ns/ldp",

"@type": "ldp:Container",

"@id": "http://inbox.rerum.io/messages?target=https://scta.info/iiif/plaoulcommentary/sorb/manifest",

"contains": [

{

"@id": "http://inbox.rerum.io/id/-L5UNLWrdYJwxgatb-z4",

"@context": "http://iiif.io/api/presentation/2/context.json",

"@type": "Announce",

"actor": {

"@id": "https://scta.info",

"label": "SCTA"

},

"motivation": "supplementing",

"object": {

"@id": "https://scta.info/iiif/plaoulcommentary/sorb/layer/transcription",

"@type": "sc:Layer",

"attribution": "SCTA",

"description": "A Transcription Layer for Plaoul Sorb",

"license": "creative commons link",

"logo": "http://scta.info/logo.png"

},

"published": "Fri Feb 16 16:10:16 UTC 2018",

"target": "https://scta.info/iiif/plaoulcommentary/sorb/manifest"

},

]

}

​

https://scta.info/iiif/plaoulcommentary/sorb/layer/transcription

Open an institutional manifest with no ranges or transcriptions

Import Range

Learn about available transcriptions

Import transcriptions

Other Applications

Error Reporting

Distribution and Discovery

Sharing Links

Peer Review

Flag Planting

A Draft Specification

inbox-docs.rerum.io#!/specifications

Basic Uses Inbox to connect IIIF content

1. Submit an announcement: POST an object to http://inbox.rerum.io/messages.
2. Retrieve announcements for an object: GET inbox.rerum.io/messages?target=URI.
3. Modify an announcement: PUT inbox.rerum.io/id/[ID] for replacement.
4. DELETE and PATCH are not currently supported.

​

Service Block: To be included in a manifest a service block

"service": {� "@context": "http://www.w3.org/ns/ldp#inbox",�"@id":"http://inbox.rerum.io/messages?target=http://example.com/book1/manifest.json",�"inbox":"http://inbox.rerum.io/messages?target=http://example.com/book1/manifest.json"� "profile": "http://www.w3.org/ns/ldp#inbox",� "label": "Linked Data Notifications inbox"�}�The @id and inbox and the @context and profile property pairs SHOULD match and both be present to allow the service to be recognized by both the internal context and the generic IIIF JSON-LD service block protocols.

​

{� "@context": "http://iiif.io/api/presentation/2/context.json",� "@type": "as:Announce",� "motivation": "supplementing",� "actor":{� "@id": "https://scta.info/#identity”,� "label": "SCTA"� },� "target": "http://inbox.rerum.io?target=http://example.com/book1/manifest.json",� "Object": {�"@id":"http://scta.info/iiif/lombardsententia/bnf15705/ranges/toc/wrapper”,� "@type":"sc:Range",� "attribution": "Created by Joe",� "description": "Table of Contents missing from the published Sequence.",� "license": "https://creativecommons.org/licenses/by-sa/4.0/",� "logo": "http://link.to.logo.png"� }�}

POST Payload: To be sent via a POST request to the value of the inbox property in the manifest service block

Example Url http://inbox.rerum.io/messages?target=https://scta.info/iiif/plaoulcommentary/sorb/manifest

Example Response

{

"@context": "http://www.w3.org/ns/ldp",

"@type": "ldp:Container",

"@id": "http://inbox.rerum.io/messages?target=https://scta.info/iiif/plaoulcommentary/sorb/manifest",

"contains": [ {array of notification objects}, ... ]

}

Inbox Payload: To be return by inbox, when target manifest id is provided

{� "@id": "http://inbox.rerum.io/id/1",� "@context": "http://iiif.io/api/presentation/2/context.json",� "@type": "as:Announce",� "motivation": "supplementing",� "published": "2017-01-02",� "actor":{� "@id": "https://scta.info/#identity",� "label": "SCTA"� },� "target": "http://example.com/book1/manifest.json",� "object": {� "@id":"http://scta.info/iiif/lombardsententia/bnf15705/ranges/toc/wrapper",� "@type":"sc:Range",� "attribution": "Created by Joe",� "description": "Table of Contents missing from the published Sequence.",� "license": "creative commons link"� "logo": "http://link.to.logo.png"� }�}�

Basic structure of individual notifications: To be returned by an inbox when an inbox notification id is dereferenced

Next steps

• If this going to become a global possibility, we need the specification and design pattern to be adopted as a community standard.
• If there is enough interest, we need to begin a path towards a technical specification group as described here: http://iiif.io/community/groups/framework/#technical-specification-group-formation-and-approval
• Steps to forming a technical group
• Begin google doc outlining “inter-institutional convergence on common models” and “shared needs”
• Submit google doc for review by community
• If approved, formation of group charter
• Call for participation
• “At least three IIIF participating institutions must respond positively, and no more than three institutions may respond negatively”
• How does this overlap with the discovery group? It seems discovery related but out of scope of the discovery group’s current focus.

​