Demo scenario ErfgoedPod

A Collection of Interesting Ideas,

This version:
https://mellonscholarlycommunication.github.io/spec-usecases/heritage-scenario.html
Issue Tracking:
Inline In Spec
Editor:
(meemoo)

CC0 To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 2 November 2021, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

Abstract

This document describes the scenario for the first ErfgoedPod demo.

1. Introduction

The goal of the ErfgoedPod demo is to illustrate the components and architecture of the decentralized artefact exchange network in combination with the the collection registration system Solid CRS, developed by Digita for the "Solid for small heritage institutions" project.

2. Scenario

2.1. Pre-conditions

2.1.1. Maintainers

Bob: collection maintainer at a cultural heritage institution

2.1.2. Solid Pods

Institution’s Pod: data pod containing all digital heritage files of Bob's institution

2.1.3. Orchestrators

Institution’s Orchestrator: takes care of the communication (sending notifications) on behalf of Bob.

2.1.4. Solid Apps

Solid CRS: collection management system for small digital heritage organizations

Demo Dashboard: demo frontend to illustrate communication between different pods and services

2.1.5. Service hubs

Registry Service Hub

Archival Service Hub

2.2. Part 1: artefact creation

  1. Bob logs into Solid CRS with his Web ID

  2. Bob creates a new Collection "Utrecht WOII" about Utrecht in WOII.

  3. He adds an object with the following metadata

  4. This results in a new artefact https://pod.inrupt.com/mvs/heritage-collections/catalog#collection-d241c975-42fa-41ab-9ff9-3918ee22085a of type schema:Dataset:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix schema: <http://schema.org/> .
@prefix collections: <https://pod.inrupt.com/mvs/heritage-collections/catalog#> . 
@prefix objects: <https://pod.inrupt.com/mvs/heritage-objects/> .

collections:collection-d241c975-42fa-41ab-9ff9-3918ee22085a
        schema:name  "Utrecht WOII"@nl ;
        schema:description  "Utrecht in WOII"@nl ;
        schema:distribution  collections:distribution-16008f15-9f8e-4acc-9e9a-f60f53e1a8a2 ;
        rdf:type             schema:Dataset .

collections:distribution-d92aeb56-5f23-44ca-afd9-ec46ed0c6ee3
        rdf:type                        schema:DataDownload ;
        schema:contentUrl  objects:data-bbc0118e-7ba8-47ab-a532-fae62e2281fb .

objects:data-bbc0118e-7ba8-47ab-a532-fae62e2281fb#object-214e970e-48f2-48a1-a90f-add11f31a64a
        schema:height      objects:data-bbc0118e-7ba8-47ab-a532-fae62e2281fb#object-214e970e-48f2-48a1-a90f-add11f31a64a-height ;
        schema:isPartOf    collections:collection-d241c975-42fa-41ab-9ff9-3918ee22085a ;
        schema:weight      objects:data-bbc0118e-7ba8-47ab-a532-fae62e2281fb#object-214e970e-48f2-48a1-a90f-add11f31a64a-weight ;
        schema:locationCreated  <http://www.wikidata.org/entity/Q39297398> ;
        schema:dateCreated  "1945-05-07" ;
        schema:name        "Bevrijding Utrecht."@nl ;
        schema:description  "Bevrijding Utrecht. Overweg Burgemeester Reigerstraat."@nl ;
        rdf:type                        schema:CreativeWork ;
        schema:mainEntityOfPage  objects:data-bbc0118e-7ba8-47ab-a532-fae62e2281fb#object-214e970e-48f2-48a1-a90f-add11f31a64a-digital ;
        schema:additionalType  <https://data.niod.nl/WO2_Thesaurus/events/9314> ;
        schema:depth       objects:data-bbc0118e-7ba8-47ab-a532-fae62e2281fb#object-214e970e-48f2-48a1-a90f-add11f31a64a-depth ;
        schema:identifier  "1" ;
        schema:width       objects:data-bbc0118e-7ba8-47ab-a532-fae62e2281fb#object-214e970e-48f2-48a1-a90f-add11f31a64a-width .

  1. Solid CRS stores the artefact in the Institution’s Pod.

  2. The new artefact triggers an as:Create activity about the artefact.

  3. A Linked Data Notification containing the activity is posted to Institution’s Pod's inbox.

2.3. Part 2: requesting services

2.3.1. Invoking the registration service

  1. Bob turns to the demo dashboard of the artefact exchange network and logs in with his WebID.

  2. The demo dashboard connects the Institution’s Pod for the first time

  3. The demo dashboard prepares the Institution’s Pod for network participation by creating an event log resource. This log tracks all lifecycle events of an artefact.

  4. Bob can view the artefact + inbox and event log

  5. Bob enters the inbox URI of the Institution’s Orchestrator in the demo dashboard

  6. The demo dashboard connects to the Institution’s Orchestrator by informing it about the Institution’s Pod's inbox.

  7. The Institution’s Orchestrator reads the as:Create activity from the Institution’s Pod's inbox

    • appends the creation event to the event log

  8. The Institution’s Orchestrator suggests to Bob that he should offer the artefact metadata to the Registry Service Hub.

  9. Bob sees the suggestions in the demo dashboard and decides to follow through.

  10. In the demo dashboard, Bob selects the object from § 2.2 Part 1: artefact creation as artefact.

  11. Bob selects the Registry Service Hub as target from the list.

  12. Bob initializes the offer.

  13. demo dashboard creates a new notification with an as:Offer

    • adds a short note

  14. The Institution’s Orchestrator forwards the notification to the Registry Service Hub.

  15. The Registry Service Hub receives the notification

  16. The Registry Service Hub sends a notification with as:Announce to the Institution’s Pod's inbox.

  17. The Institution’s Orchestrator reads the as:Announce activity from the inbox.

  18. Institution’s Orchestrator appends the registration event (ie. the as:Announce) to the event log in the Institution’s Pod.

  19. Bob sees in the event log with the demo dashboard that the registration is complete

2.3.2. Invoking the archival service

  1. Bob turns to the demo dashboard of the artefact exchange network.

  2. Bob sees the suggestions in the demo dashboard and decides to follow through.

  3. In the demo dashboard, Bob selects the Archival Service Hub as target from the list

  4. Bob initializes the offer.

  5. demo dashboard creates a new notification with an as:Offer activity

    • Add a short note

  6. The Institution’s Orchestrator forwards the notification to the Archival Service Hub.

  7. The Archival Service Hub receives the notification

    • downloads the artefact

    • wraps the image artefact in a bagit and adds it to meemoo’s SFTP

  8. The meemoo archival process starts.

  9. The Archival Service Hub polls meemoo’s Mediahaven API for ARCHIVED_ON_DISK premis event

  10. When found, it sends a notification with as:Announce to the Institution’s Pod's inbox.

  11. The Institution’s Orchestrator reads the as:Announce activity from the inbox.

  12. Institution’s Orchestrator appends the archival event (ie. the as:Announce) to the event log in the Institution’s Pod.

  13. Bob sees in the event log with the demo dashboard that the registration is complete

how to get to aggregation of artefacts

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119

Informative References

[LDN]
Sarven Capadisli; Amy Guy. Linked Data Notifications. 2 May 2017. REC. URL: https://www.w3.org/TR/ldn/

Issues Index

how to get to aggregation of artefacts ↵