Detailliertes Inhaltsverzeichnis

1. Einführung
2. Namensgebung
3. Medienartefakte
4. Zielsetzung
5. Recherche und Toolwahl
6. Seitenaufbau
7. Kartenmaterial
8. Georeferenzierung
9. Partizipation & Storytelling
10. Metadaten
11. Dithering via CSS
12. FAIR-Prinzipien, Linked Open Data und Ontologien
13. Defizite und Schlussbetrachtung

Einführung

Kontext Namensgebung

Dem gesamten Projekt ähnlich, handelt es sich auch bei dem Namen Raumdepot um einen Prototyp. Ich möchte kurz auf die diesbezüglichen Überlegungen eingehen. Das vorliegende Provisorium besteht für mich im Grunde aus drei separaten Ansätzen, die sich gegenseitig helfen sollen, nützlich zu sein. Ich wollte etwas bauen, dass digital, partizipativ und unkuratiert funktioniert.⁷

Digitalität

Auf der ersten Ebene der Digitalität soll eine Web-Umsetzung helfen, Medienartefakte geografisch anzuzeigen. Der räumliche Kontext eines Eintrags wird so nicht zu einem numerischen Wert, der neben unmittelbarer lesbaren Informationen auf zukünftige Interpretation hoffen muss, sondern zu einer zentralen Eigenschaft jedes Eintrags. Durch die Möglichkeiten digitaler Visualisierungen wird Kultur im Raum sichtbar. Das Raumdepot ist kein analoger Faktenstapel.

Partizipation

Eine zweite Bedeutungsebene ist jene der Partizipation.⁸ Denn auf den zweiten Blick hat der Vergleich mit den solitär sammelnden Bienen auf meinem Fenstersims mindestens ein Defizit. Auf den vorliegenden Seiten soll gesammelt und geteilt werden können. Die Struktur gibt Möglichkeiten zur Einsortierung der Inhalte. So soll einerseits die Markierung von Bedeutung und Erinnerung in Form von digital storytelling möglich sein. Die Nutzenden sollen hier völlig frei erfassen, bemerken und asoziieren dürfen. Andererseits ist die Erfassung zusätzlicher (Meta-)Informationen möglich und wichtig. Dass ein Gebiet so (unter anderem) als gemeinsamer Speicher für Sammeln, Bedeuten, Erinnern erfahrbar gemacht werden kann, wollte ich im Namen verdeutlichen. Das Raumdepot muss keine Privatablage sein.⁹

Ziellose Sammlung

Die dritte Ebene beschreibt das Ziel einer möglichst ziellosen Sammlungsaktivität. Der vorliegende Prototyp ist insofern kein Archiv im engeren Sinne.¹⁰ Er soll weitgehend ohne Mechaniken der Selektion und Kuratierung auskommen. Für die Sammlungsabsicht einschränkend ist einzig die Notwendigkeit eines räumlichen Bezugs und die Auskunft über Beziehung, Konnotation und Bezug; oder: über Bedeutung(en) der eingereichten Inhalte für die einreichenden Personen. Durch diese Offenheit werden zahllose Überschreibungen der Landschaft potenziell möglich, beziehungsweise sichtbar. Die vorliegende Plattform kann zwar ein regionalhistorisches Nachschlagewerk zur Sicherung und Sichtbarmachung von privatem historischem Material werden. Die Entwicklung eines stärkeren Gegenwartsbezugs – als etwa in Projekten wie der Topothek – ist aber zumindest möglich.¹¹ Der gewählte Name soll ein ergebnisoffenes aber aufgeräumtes Gefäss verkörpern. Das Raumdepot soll kein kuratiertes Museum sein.

Kontext Medienartefakte

«Das Kunstwerk ist grundsätzlich immer reproduzierbar gewesen. Was Menschen gemacht hatten, das konnte immer von Menschen nachgemacht werden. [. . .] Dem gegenüber ist die technische Reproduktion des Kunstwerkes etwas Neues, das sich in der Geschichte intermittierend, in weit auseinanderliegenden Schüben, aber mit wachsender Intensität durchsetzt.»

Walter Benjamin¹²

Mit Seitenblick auf Walter Benjamin möchte ich für die folgenden Gedanken einen Begriff vorschlagen. Es soll für die obigen Beispiele – und für alle weiteren Funde in Form von Einträgen auf dieser Plattform – die Rede sein von «Medienartefakten».¹³ Der Begriff erscheint mit aus zweierlei Gründen ergiebig.

Einerseits wird als Artefakt im Allgemeinen ein von Menschenhand geschaffenes Objekt oder eine Spur menschlicher Aktivität verstanden. Der Begriff kann in verschiedenen Kontexten verwendet werden, besondere methodische Bedeutung hat er unter anderem in der Archäologie. Die Konzeption der Spur scheint mir dabei wichtig, denn Artefakte können durchaus (auch) menschliche (Meta-)Belege für Nichtmenschliches sein. Diese Unterscheidung ist gerade für den digitalen Umgang mit Artefakten zentral. Oftmals ist heutzutage eine Mediendatei der Medieninhalt, manchmal aber repräsentiert sie diesen auch nur (Scans von Dokumenten, Digitalisate von Fotografien).¹⁴ In jedem Fall entstehen Medienartefakte aber nicht aus sich selbst heraus, sondern sind stets Teil eines kulturellen Überlieferungszusammenhangs.

Medienartefakte sind produzierte Hinterlassenschaften. Diese bisherige Bedeutungsdimension wird andererseits durch die Medienwissenschaft semantisch noch ergänzt. Dort bezieht sich der Begriff Medienartefakt oft auf digitale Störungen, die während der Erstellung, Bearbeitung oder Übertragung von digitalen Medieninhalten entstehen können. Inhaltlich wird hier auf die zwangsläufige, künstliche «Spur» der Kontamination durch menschliches Handeln und technische Transformation fokussiert. Digitale Artefakte in diesem Sinne können durch Kompression, Kodierung oder andere digitale Verarbeitungsprozesse entstehen und zu einer Veränderung der Bild- oder Tonqualität führen. Ein Medienartefakt hat sich in dieser Lesart bereits maximal von seinem ontologischen Ursprungskontext entfernt. Anlass und Aufnahme dürfen nicht verwechselt werden.

Um die Gedanken zur Stellvertretung, Kontamination und inhaltlichen Distanz zugänglich und nutzbar zu machen, sollte ursprünglich allen Medieneinbettungen auf dieser Plattform ein Dithering-Effekt via CSS zugewiesen werden (mehr dazu in der Dokumentation ↓). Die animierte Körnigkeit der so dargestellten Digitalisate sollte eine Art Trennschicht sein, die den zentralen Unterschied zwischen Inhalt und Wiedergabe zu visualisieren suchte. Die Lösung war nicht invasiv, die hochgeladenen Dateien bleiben davon unberührt.

Die ‹Gemachtheit› der eingereichten Dateien zu Ende denkend, erscheint es mir sinnvoll, die Artefakte in einem ersten Schritt durch digital storytelling subjektiv zu erfassen. Hochladende Nutzer*innen teilen nicht nur, sie teilen sich mit. Deshalb wird bei jeder Einreichung eines Medienartefakts erst einmal nach Produktionsbegründungen, persönlichen Bezügen, Interpretationen oder Bedeutungen gefragt (↓Dokumentation Partizipation). In einem zweiten Schritt werden dann die technische(re)n Metadaten notiert.¹⁶

Zielsetzung

Die experimentelle Zielsetzung des Raumdepots ist es, raumbezogene Medieninhalte digitalisiert über das Internet verfügbar zu machen. Dies soll partizipativ möglich sein. Die Medienartefakte werden als Dateien insofern aber nur stellvertretend deponiert. Das hauptsächliche – eigentliche – Interesse gilt der Frage nach der subjektiven Konnotation der Einreichungen. Hierbei kann die persönliche Bedeutung hinterlegt, die Relevanz für andere notiert oder schlichtes Hörensagen deponiert werden. Im Raumdepot finden Sie die Bild-, Video-, Ton- oder Dokumentinhalte sortiert nach:

– Medienart
– Schlagworten
– Kartenausschnitt

Der Sammlungsfokus liegt dabei stark auf der Perspektive der Personen, die ein Medienartefakt einreichen. Ihre Verstrickungen mit den eingereichten Dateien sind es, die kartographiert werden sollen. Durch die inhaltliche Offenheit entstünde im Idealfall das Potenzial eines third spaces im Sinne von unerwarteten Entdeckungen, Zufallsfunden und einem erweiterten Raumverständnis.¹⁷

Die folgende Dokumentation soll Aufschluss geben über Probleme und Lösungen, die gewählten Werkzeuge und Methoden.

Dokumentation Recherche und Toolwahl

Das Projekt digital umzusetzen hiess für mich, es webbasiert realisieren zu wollen. In dieser Umgebung und mit den Programmiersprachen fühle ich mich als Laie wohl. Ich habe keinen Hintergrund in (Web-)Entwicklung aber wollte etwas bauen, dass trotzdem nutzbar und nützlich sein könnte. Ich habe die naheliegenden webbasierten Plattformen Nodegoat und Omeka untersucht. Nicht zum letzten Mal motivierten mich hier allerdings die jeweils weiteren zwei meiner drei Ursprungsmotive dazu, mich für eine andere Lösung zu entscheiden. So bietet Nodegoat zwar unter anderem eine überwältigende Vielfalt an Möglichkeiten, Datenbestände zu erheben und zu verarbeiten. Die dadurch aufwändig bis unmögliche Implementation eines gemeinschaftlichen Ansatzes machten die Plattform für mein Vorhaben aber nicht sinnvoll. Omeka liess sich in Versuchen zwar gut auch für Projekte mit eher wenigen Metadaten und kleinen Ontologie nutzen. Auch hier fehlten mir jedoch die Möglichkeit kollektiver Nutzung.¹⁸ Damit ist nicht nur das Beitragen von Informationen gemeint, sondern zwingend auch die niederschwellige und ansprechende Zugänglichkeit der visuellen Darstellung.

Denn die Oberfläche sollte nicht nur die Möglichkeit beinhalten, dass Nutzer*innen eigene Medienartefakte beitragen können, sondern, dass Sie sich dazu auch eingeladen fühlen. Der Anspruch schränkte an dieser Stelle die Auswahl an möglichen Werkzeugen weiter ein. Für den einladenden Charakter wollte ich bereits auf der Eingangsseite in Form eines masonry grids auf die Fülle an Funden aufmerksam machen und zum Stöbern einladen. Die unterschiedlichen Beiträge, Medienarten und Erschliessungsdichten sollten ‚endlos‘ nach unten scrollbar sein und motivieren, einen eigenen Beitrag hochzuladen. Auch das ‚Eintauchen‘ per Klick in ein einzelnes Artefakt sollte aufgeräumt und unkompliziert wirken. Diese Funktionalitäten decken die meisten CMS ab. In der Bedienung ansprechend finde ich beispielsweise Readymag oder Cargo. Ein Nachteil der meisten kommerziellen Produkte in diesem Bereich ist aber der fehlende open source Ansatz, die minimale Dokumentation und die wenigen Erweiterungsmöglichkeiten. Ich suchte eine möglichst skalierbare, offene und vielbesprochene Plattform.

Aufgrund der vielen grafischen Möglichkeiten, dem nachvollziehbaren Codeaufbau, den zahlreichen verfügbaren Plugins und schliesslich der grossen Community entschied ich mich für einen selbstgehosteten WordPress-Build (WordPress 6.4.1). Die zahlreichen Erweiterungs- und Gestaltungsmöglichkeiten werden unten erklärt. Auf die Defizite von CMS wie Readymag, Cargo oder WordPress bzgl. den FAIR-Kriterien und Archivierungsstandards wird weiter unten eingegangen (↓FAIR).

Dokumentation Seitenaufbau

Der Seitenaufbau orientiert sich in seiner Grundstruktur am Gerüst Eksell von Anders Norén. Die Systemfarben wurden überschrieben und Attribute einzelner Seiten wurden z.B. für bessere Darstellung auf Mobilgeräten editiert.

.single-nav {
	display: none !important;   
}
.single {
  max-width: 60%;
	display: block;
	width: 100%;
	float: none !important;
	margin-left: auto;
	margin-right: auto;
}
.wpsl-map {
	border: 0px solid white;
  border-radius: 50px;	
}
@media only screen and (max-width: 600px) {
  .page-id-64 {
    width: 100% !important;
    margin: 1rem auto;
    text-align: justify;
    opacity: 1;
  }
}

Für das Design wird zwischen Übersicht, Detailansicht Medienartefakt und Einzelseite unterschieden. Die Übersicht übernimmt grundsätzlich das masonry Grid des Eksell-Designs und dessen Filtermöglichkeiten. Die Detailansicht einer einzelnen Einreichung wurde hingegen komplett neu geschrieben (und mit <?php if (is_single()) beziehungsweise <?php else ausgeführt). Ich wollte eine Gegenüberstellung von Dateiwiedergabe vs. der erzählten Kontextinformationen plus Metadaten erreichen. Ich finde, dies ist mit dem zweispaltigen Layout auf Desktop und einer Untereinander-Ansicht auf Mobile gut gelungen. Zudem wurde für die Dokumentation und andere Einzelseiten ein eigenes ein-Spalten-Design entworfen.

Der gesamten Seite wurde eine basale Seitennavigation für Karte 📍, Suche 🔎, Einreicheformular 📸, Dokumentation 🧠, Tags 🧩 und Home 🏠 auf Basis von eckenfixierten Emojis geschrieben. Der Verweis auf Home wird nur auf Unterseiten angezeigt

.mitte{
position: fixed;
bottom: 0rem; 
left: 50%;
font-size: 5rem;
z-index: 999;
text-decoration: none;
}
.mitte a{
text-decoration: none;
}
.topleft {
position: fixed;
top: 0rem; 
left: 0rem; 
font-size: 5rem;
z-index: 999;
text-decoration: none;
}
.topleft a {
text-decoration: none;
}
.left {
position: fixed;
bottom: 0rem; 
left: 0rem; 
font-size: 5rem;
z-index: 999;
}
.left a {
text-decoration: none;
}
.topright {
position: fixed;
top: 0rem; 
right: 0rem; 
font-size: 5rem;
z-index: 999;
text-decoration: none;
}
.topright a {
text-decoration: none;
}
.right {
position: fixed;
bottom: 0rem; 
right: 0rem; 
font-size: 5rem;
z-index: 999;
text-decoration: none;
    }
.right a {
text-decoration: none;
}

Die Schriften werden von der Google Fonts API gehandhabt.

Dokumentation Kartenmaterial

Da sich das vorliegende Projekt eine visuell ansprechende Darstellung vorgenommen hat, wäre die Einbettung von komplett selbst erstellten Kartenmaterials wünschenswert gewesen. Mapbox Stil und Tileset wurden hierfür bereits generiert. Grundlage des Tilesets sind zwei frei verfügbare Datensätze von swisstopo.

Zum einen wurde die Idee der räumlichen Eingrenzung der Eintragungen konsequent in das Kartenmaterial übersetzt. Hierzu wurden die öffentlich verfügbaren Kantonsgrenzen für Obwalden via QGIS invertiert und mit dem Gesamtschweizerischen Territorium geschnitten. Beides ist im Datensatz swissBOUNDARIES3D enthalten. Zum anderen wurde das digitale Höhenmodell DHM25 implementiert, um die in diesem Halbkanton häufige Situation der Hanglage sichtbarer zu machen und die Kessel des Sarneraa- und Engelbergeraatals zu visualisieren.¹⁹

Für die Verknüpfung der eingesandten Beiträge (→Dokumentation Partizipation) mit dem via Mapbox erstellten Kartenmaterials wäre ursprünglich das Plugin Treweler (Version 1.12) vorgesehen gewesen. Der Handover von numerischen Koordinatendaten in eine via Treweler angezeigte Mapbox-Karte hat sich allerdings als nicht sinnvoll umsetzbar herausgestellt. Eine Injection der Formulardaten in eine Mapboxkarte müsste möglich sein, das visuell ansprechende Treweler-Plugin ist hierfür allerdings leider die falsche Wahl. Somit bleibt es bei folgendem Prototypen vom April 2023:

Deshalb wurde in einem nächsten Schritt die Umsetzung mit Google Maps angestrebt. Der Konzern bietet mit der Cloudlösung Google Maps Platform ein Werkzeug zum Design eigener Kartendaten an. Bei folgender Karte wären sämtliche Kartendaten (swissBOUNDARIES3D/DHM25, gemäss Beispiel via Mapbox oben) hinterlegt, sie kann momentan (Stand November 2023) jedoch nur in Android/iOS-Applikationen integriert, nicht aber per JavaScript im Web eingebettet werden.

map = new google.maps.Map(document.getElementById('map'), {
center: {lat: -34.397, lng: 150.644},
zoom: 8,
mapId: 'b359353f8f6a37a2'
});

Stattdessen wird durch den Google Maps Style Wizard eine eigene Farbwahl und das Ein- und Ausblenden unterschiedlicher Informationsebenen angeboten. So entstand die folgende, aktuelle Karte (Stand November 2023). Die Eintragungen werden via Simple Locator Plugin und dem Shortcode [simple_locator_all_locations] zusammengezogen (siehe ↓Dokumentation Georeferenzierung).

.gm-style-iw {
  background-color: rgb(0, 0, 0) !important;
  padding: 0rem !important;
  border: 0px solid white;
  border-radius: 0px !important;
  overflow: hidden;	
}
.infowindow-container {
  position: relative;
  display: flex;
  height:inherit;
}
.post-thumbnail {
  position: relative;
}
.post-thumbnail img {
  height: 30vh;
  width: auto;
}
.post-details {
  position: absolute;
  margin-top: 0;
  flex-grow: 1; 
  overflow: hidden;
}
.gm-style-iw {
  overflow-y: auto !important;
  overflow-x: hidden !important;
}
.gm-style-iw > div {
  overflow: visible !important;   
}
.gm-ui-hover-effect{
  opacity: 1!important;
}
.infoWindow {
  overflow: hidden !important;
}
.wpsl-map {
  height: 75vh;
}

<script type="text/javascript">
 //map.js
var map; 
var marker = false;
function initMap() {
    var centerOfMap = new google.maps.LatLng(46.8975, 8.2478);

    var customStyles = [
  {
    "elementType": "geometry",
    "stylers": [
      {
        "color": "#000000"
      }
    ]
  },
  {
    "elementType": "labels.icon",
    "stylers": [
      {
        "visibility": "off"
      }
    ]
  },
  {
    "elementType": "labels.text.fill",
    "stylers": [
      {
        "color": "#757575"
      }
    ]
  },
  {
    "elementType": "labels.text.stroke",
    "stylers": [
      {
        "color": "#212121"
      }
    ]
  },
  {
    "featureType": "administrative",
    "elementType": "geometry",
    "stylers": [
      {
        "color": "#444444"
      }
    ]
  },
  {
    "featureType": "administrative.country",
    "elementType": "labels.text.fill",
    "stylers": [
      {
        "color": "#9e9e9e"
      }
    ]
  },
  {
    "featureType": "administrative.land_parcel",
    "stylers": [
      {
        "visibility": "off"
      }
    ]
  },
  {
    "featureType": "administrative.locality",
    "elementType": "labels.text.fill",
    "stylers": [
      {
        "color": "#bdbdbd"
      }
    ]
  },
  {
    "featureType": "poi",
    "stylers": [
      {
        "visibility": "off"
      }
    ]
  },
  {
    "featureType": "poi",
    "elementType": "labels.text.fill",
    "stylers": [
      {
        "color": "#757575"
      }
    ]
  },
  {
    "featureType": "poi.park",
    "elementType": "geometry",
    "stylers": [
      {
        "color": "#181818"
      }
    ]
  },
  {
    "featureType": "poi.park",
    "elementType": "labels.text.fill",
    "stylers": [
      {
        "color": "#616161"
      }
    ]
  },
  {
    "featureType": "poi.park",
    "elementType": "labels.text.stroke",
    "stylers": [
      {
        "color": "#1b1b1b"
      }
    ]
  },
  {
    "featureType": "road",
    "elementType": "geometry.fill",
    "stylers": [
      {
        "color": "#2c2c2c"
      }
    ]
  },
  {
    "featureType": "road",
    "elementType": "labels.text.fill",
    "stylers": [
      {
        "color": "#8a8a8a"
      }
    ]
  },
  {
    "featureType": "road.arterial",
    "elementType": "geometry",
    "stylers": [
      {
        "color": "#373737"
      }
    ]
  },
  {
    "featureType": "road.highway",
    "elementType": "geometry",
    "stylers": [
      {
        "color": "#3c3c3c"
      }
    ]
  },
  {
    "featureType": "road.highway.controlled_access",
    "elementType": "geometry",
    "stylers": [
      {
        "color": "#4e4e4e"
      }
    ]
  },
  {
    "featureType": "road.local",
    "elementType": "labels.text.fill",
    "stylers": [
      {
        "color": "#616161"
      }
    ]
  },
  {
    "featureType": "transit",
    "elementType": "labels.text.fill",
    "stylers": [
      {
        "color": "#757575"
      }
    ]
  },
  {
    "featureType": "water",
    "elementType": "geometry",
    "stylers": [
      {
        "color": "#ffffff"
      },
      {
        "lightness": -75
      }
    ]
  },
  {
    "featureType": "water",
    "elementType": "labels.text.fill",
    "stylers": [
      {
        "color": "#3d3d3d"
      }
    ]
  }
];				
</script>

Die Darstellung der angeklickten Eintragungsvorschau wurde dem Gesamtauftritt entsprechend angepasst. Es wurde ein Clustering von Eintragungen programmiert, das auf Übersichtlichkeit in tiefen Zoomstufen ausgelegt ist. Die Einzelinhalte fächern sich also erst recht ‹weit unten› auf. Einer der (wenigen) Vorteile einer GoogleMaps-Implementation ist übrigens die grosse Dokumentation und Vielfalt an Problemlösungen. Für den Ausweg nach stundenlanger Arbeit am close-Button der angeklickten Eintragungsvorschau danke ich beispielsweise dieser Lösung von Simon East.

Dokumentation Georeferenzierung

Die Georeferenzierung wird durch eine Modifikation des Simple Locator Plugins (Version 2.0.3) von Kyle Phillips gelöst. Das Zusatzmodul ermöglicht die Verknüpfung sämtlicher WordPress post types mit Adressdaten als Strings oder in Form von numerischen Werten zu Längen- und Breitengrad. Hier wird Letzteres genutzt. Die numerischen Gradangaben können in zwei proprietären Simple Locator fields oder in bereits existierenden custom fields der Umgebung gespeichert werden. Da das Partizipationsmodul später diese zwei Werte $lat und $lng im Beitragsformular mittels JavaScipt Kartenwahl abfragen und dem Beitrag anhängen soll, werden zwei custom fields verwendet (siehe ↓ Dokumentation Partizipation). Die Ortsabfrage stellte mich vor grosse Komplikationen, wurde schliesslich aber als map.js wie folgt geschrieben und eingebettet.

<script type="text/javascript" src="https://maps.googleapis.com/maps/api/js?key=AIzaSyDP4dP2xjkuAmj3wl1VdPbPN72qnoUKdAU&callback=initMap"></script>
        <!--map div-->
        <div id="map"></div>
<script type="text/javascript">
 //map.js
var map; 
var marker = false; 
        
function initMap() {			
    //Hauptort Sarnen als Kartenmittelpunkt.
    var centerOfMap = new google.maps.LatLng(46.8975, 8.2478);
var options = {
  center: centerOfMap,
  zoom: 11, 
  styles: customStyles 
};
    map = new google.maps.Map(document.getElementById('map'), options);
    google.maps.event.addListener(map, 'click', function(event) {                
        var clickedLocation = event.latLng;
        if(marker === false){
            
            marker = new google.maps.Marker({
                position: clickedLocation,
                map: map,
                draggable: true 
            });
       google.maps.event.addListener(marker, 'dragend', function(event){
                markerLocation();
            });
        } else{
            marker.setPosition(clickedLocation);
        }
        //Get the marker's location.
        markerLocation();
    });
}
        
//This function will get the marker's current location and then add the lat/long values to our custom fields so that we can save the location.
function markerLocation(){
    var currentLocation = marker.getPosition();
    document.getElementById('lat').value = currentLocation.lat(); //latitude
    document.getElementById('lng').value = currentLocation.lng(); //longitude
}       
google.maps.event.addDomListener(window, 'load', initMap);
</script>

<div hidden>
<input name="usp-custom-latitude" id="lat" type="text" value="" data-required="true" placeholder="In Karte klicken..." class="example-class-3 usp-input usp-input-custom usp-form-422">
<input name="usp-custom-longitude" id="lng" type="text" value="" data-required="true" placeholder="In Karte klicken..." class="example-class-2 usp-input usp-input-custom usp-form-422">
</div>

Die lat- und lng-id werden nun dynamisch (aber für die Nutzenden versteckt) weitergegeben ($lat → usp-custom-field-1; $lng → usp-custom-field-2). Siehe ↓Dokumentation Partizipation. Die aktuelle Umsetzung der Georeferenzierung birgt mindestens zwei Defizite, siehe ↓ Defizite.

Dokumentation Partizipation & Storytelling

Die Partizipationsmöglichkeit basiert auf dem User Submitted Posts Modul von Jeff Starr (kostenpflichtige Vollversion). Im Prinzip wird so ermöglicht, über die Einbettung einer Maske via Frontend Informationen einzuspeisen, die als genuine Wordress-Beiträge im Backend verarbeitet und angezeigt werden können. Es sollen insgesamt zwölf Informationen für jeden Beitrag erhoben werden (mehr dazu siehe in der ↓Dokumentation Metadaten). Das Plugin User Submitted Posts kann die Einreichungen in sämtlichen verfügbaren post types übergeben.²⁰ Für den vorliegenden Fall werden die Einreichungen von Nutzer*innen als klassischer post erstellt.

digital storytelling

Die Grundstruktur eines post besteht aus Beitragstitel, -inhalt, -kategorie und -tags. Sie wird mit folgenden vier Feldern angesprochen: title, content, category und tags. Zentral ist neben den unten folgenden Feldern der Metadaten vor allem das Pflichtfeld content («Beschreibung Medienartefakt»). In einem klassischen WordPress-Beitrag trüge diese Klasse sämtliche Textinformationen einen Blogbeitrags. Auf der vorliegenden Plattofrm werden Nutzer*innen mit diesem Feld gebeten, den Inhalt der hochzuladenden Datei möglichst umfassend zu beschreiben. Was ist in den Daten enthalten? Was ist zu sehen/zu hören/zu lesen? In welchen Kontext setzen die Nutzenden diesen Inhalt? Wie wurden die Daten erstellt? Warum wurden die Daten erstellt? Welche Konnotation oder Erinnerung verbinden sie mit dem Medienartefakt? Diese Metainformation bildet das Potenzial für digital storytelling. Ergänzt wird dieses Storytelling durch weitere, individuell geschriebene Felder.

Dokumentation Metadaten

Denn es gibt für WordPress auch die Möglichkeit, einem post Felder anzufügen, die dieser Beitragssart nicht inherent sind. Zu diesen custom fields schreibt die Dokumentation: «WordPress has the ability to allow post authors to assign custom fields to a post. This arbitrary extra information is known as metadata.»²¹

Grundsätzlich war das Ziel, ein niederschwelliges Partizipationsangebot zu präsentieren. Sicher könnten deutlich mehr Informationen von den Beitragenden erfragt werden. Die Vermutung geht jedoch dahingehend, dass dies einen Einpflegeprozess zu komplex machen könnte. Welche Informationen sind also warum von Wert für diese Plattform?

E-Mail-Adresse

Fangen wir (fast) zu unterst an. Das Feld usp_email fragt, wie bereits erwähnt, die E-Mailadresse der Nutzer*innen ab. Jeder Beitrag hat also eine nachvollziehbare Autor*innenschaft. Es wurde allerdings entschieden, die Autor*inneninformationen nicht im Frontend anzuzeigen. Sollte dies in Zukunft nötig sein, müsste ein zusätzliches custom field abgefragt werden, da die E-Mailadresse nicht als Identifikator öffentlich geteilt werden sollte. Das Feld ist ein Pflichtfeld.

Name Urheber*in

Das erste Feld usp_name meint folgerichtig nicht zwingend den Namen der Nutzer*innen, sondern soll die Urheber*innensschaft des eingereichten Medienartefakts abfragen. Wer eine Videoaufnahme einer durchs Melchtal fliegenden Gemse von seiner Grosssmutter zugeschickt bekommen hat, soll diese Datei hier mit Verweis auf die Grosssmutter eintragen dürfen. Der Wert dieses Feldes wird im Frontend angezeigt. Das Feld ist kein Pflichtfeld.

Datum

Das Feld usp_custom_field form="422" id="1" fragt das Erstellungsdatum des Medienartefakts nach. Dieser Wert wird im Frontend angezeigt. Die Nutzenden werden aufgefordert, jenes Datum einzutragen, an dem das Medienartefakt entstanden ist. Die Uhrzeit spielt keine Rolle. Um Verwechslungen mit dem (womöglichen) inhaltlichen Zeitbezug zu vermeiden, wird der Tipp gegeben, dass Einträge ab 1980 und früher eher unwahrscheinlich sind. Zwar wurde überlegt, die Unterscheidung zwischen Medieninhalt und Medienartefakt für die Zeitlichkeit(en) abzubilden. Bei der Personenreferenzierung ist dies etwa gut möglich (Urheber*in vs. Einsender*in vs. Protagonist*in, siehe unten). Eine testweise Implementation eines weiteren Datenfelds wirkte aber zu überladen. Diese Erschliessungsreduktion stellt z.B. bei realweltlichen Fotografien kein Problem dar. Der im Artefakt abgebildete Zeitbezug ist mit der Artefaktentstehung ohnehin identisch. Bei Medienartefakten mit von der Quellenzeit abweichendem Enstehungsdatum (Scan einer Archivquelle, Retrodigitalisierung Videomaterial, etc.) muss auf die Erschliessung des der Quelle inheränten Zeitbezugs verzichtet werden. Diese Entscheidung wird damit gerechtfertigt, dass ein gesichertes Entstehungsdatum bereits für viele Dateien eine wichtige Information darstellt. Medienartefakte, die durch Digitalisierung historischer Belege entstanden sind, werden aber zugunsten einer einfacheren Partizipation auf diesem Weg momentan weniger gut erschlossen. Das Feld ist ein Pflichtfeld.

Längengrad/Breitengrad

Das Feld usp_custom_field form="422" id="2" transportiert den Längengrad des Ortsbezugs des Medienartefakts. Das Feld usp_custom_field form="422" id="3" beinhaltet den Breitengrad des Ortsbezugs des Medienartefakts. Beide Werte werden in der schliesslichen Detailansicht eines Medienartefakts angezeigt, in der EIngabemaske erhalten diese beiden Felder ihre Werte versteckt vom Javascript (↑Dokumentation Georeferenzierung). Die Beitragenden werden gebeten, eine möglichst präzise kontextuelle Verortung des Medienartefakts vorzunehmen. Unscharfe Lokalisierungen oder räumliche Kontexte sollen auf ihren wahrscheinlichsten Mittelpunkt kondensiert werden.²⁴ Grundsätzlich gilt, dass die Beitragenden einen sinnvollen Raumbezug herstellen sollen. Genuin sinnvoll ist sicher der Entstehungsort. Wenn die originalinhaltliche Verortung unklar ist, kann stattdessen der Ort der Digitalisierung angegeben werden. Möglich und ausdrücklich erlaubt sind aber auch ‹Übersetzungsleistungen›, also die Notierung eines persönlichen Raumbezugs einer Mediendatei unabhängig zu deren Entstehungsort. Diese Raumbezüge müssen allerdings dementsprechend in der schriftlichen Beschreibung gekennzeichnet werden. Beide Felder sind automatisch ausgefüllte Pflichtfelder.

Protagonist*in(nen)

Das Feld usp_custom_field form="422" id="4" fragt nach inhaltlichen Protagonist*in(nen) des Medienartefakts. Welche Person vermittelt den Inhalt des Medienartefakts? Welche Menschen sind massgeblich auf einer Aufnahme zu sehen? Wer ist in einer Audiodatei zu hören? Wer hat ein Dokument verfasst oder spricht darin? Dieser Wert wird im Frontend angezeigt. Das Feld ist kein Pflichtfeld.

Institutioneller Kontext

Das Feld usp_custom_field form="422" id="5" fragt nach dem institutionellen Kontext des Medienartefakts. Welche Institution, beispielsweise ein Archiv, vermittelt den Inhalt des Medienartefakts? Bei privaten Aufnahmen werden die Einsender*innen gebeten, das Feld leer zu lassen. Dieser Wert wird im Frontend angezeigt. Das Feld ist kein Pflichtfeld.

Die values der zwölf Metadatenfelder werden mit folgendem Befehl für jeden Beitrag eines Medienartefakts im Frontend via singular.php angezeigt.

<?php
$post = get_post($post_id);
$title = $post->post_title;
$posttype = $post->post_type;
$file_category = get_the_category($post_id);
$permalink = get_permalink($post_id);
$link = usp_get_meta(false, 'usp-file-1');
$link_2 = usp_get_meta(false, 'usp-file-2');
$link_3 = usp_get_meta(false, 'usp-file-3');
$link_4 = usp_get_meta(false, 'usp-file-4');

$attached_files = array();
$attached_file_types = array();
for ($i = 1; $i <= 4; $i++) {
    $file_key = 'usp-file-' . $i;
    $file_url = usp_get_meta(false, $file_key);
    if (!empty($file_url)) {
        $attached_files[] = $file_url;
        $file_category = get_the_category($post_id);
        $attached_file_types[] = !empty($file_category) ? $file_category[0]->name : '';
    }
}

//Überprüfen, ob es sich um einen //"Audio"- oder "Video"-Beitrag oder um //einen Beitrag in der Kategorie "Bild" //oder "Dokument" mit zwei oder mehr //Dateianhängen handelt
if (
    ($file_category[0]->name === 'Audio' || $file_category[0]->name === 'Video')
    || (($file_category[0]->name === 'Bild' || $file_category[0]->name === 'Dokument') && count($attached_files) >= 2)
) {
    echo '<div class="linie"></div>';
    echo '<div class="metadaten">';
    echo '<b>Wiedergabe Medienartefakt(e)</b>';
    echo '<p><br></p>';
    //Angehängte Dateien anzeigen
    foreach ($attached_files as $index => $file_url) {
        $file_type = $attached_file_types[$index];

        //Wrapper-Div mit 50% Breite für jede Datei, um sie in einer Reihe anzuzeigen
        $wrapper_style = (count($attached_files) >= 2) ? 'width: 50%; box-sizing: border-box; float: left; padding: 1rem 1rem;' : 'width: 100%; box-sizing: border-box;';

        echo '<div class="file-wrapper" style="' . esc_attr($wrapper_style) . '">';
        //Dateityp überprüfen und entsprechend anzeigen
        if ($file_type === 'Bild') {
            //Bild als klickbaren Link anzeigen
            echo '<a href="' . esc_url($file_url) . '" target="_blank" rel="noopener noreferrer"><img src="' . esc_url($file_url) . '" alt="Bild" style="width: 100%;"></a>';
        } elseif ($file_type === 'Video') {
            //Video mit Player ohne Link anzeigen
            echo '<video controls style="width: 100%;"><source src="' . esc_url($file_url) . '" type="video/mp4"></video>';
        } elseif ($file_type === 'Dokument') {
            //Dokument als klickbaren Link anzeigen (sofern es sich um ein Bild handelt)
            echo '<a href="' . esc_url($file_url) . '" target="_blank" rel="noopener noreferrer"><img src="' . esc_url($file_url) . '" alt="Bild" style="width: 100%;"></a>';
        } elseif ($file_type === 'Audio') {
            //Audio mit Player ohne Link anzeigen
            echo '<audio controls style="width: 100%;"><source src="' . esc_url($file_url) . '" type="audio/mp3">Ihr Browser unterstützt das Audio-Tag nicht.</audio>';
        } else {
            //Andere Dateitypen als Text anzeigen
            echo esc_html($file_url);
        }
        echo '</div>'; // Wrapper schließen
    }
    echo '<div style="clear: both;"></div>';
    echo '</div>'; // metadaten-Div-Tag schließen
}
?>

<div class="metadaten">
    <b>Metadaten</b><br>
    <p><?php echo "Name / Titel / Kurzbeschreibung Medienartefakt: " . $title . ''; ?></p>
    <p><?php echo "Urheber*in, falls bekannt: " . usp_get_meta(false, 'usp-author'); ?></p>
    <p><?php echo "Protagonist*innen Medieninhalt, falls ersichtlich: " . usp_get_meta(false, 'usp-custom-protagonist'); ?></p>
    <p><?php echo "Institutioneller Kontext, falls ersichtlich: " . usp_get_meta(false, 'usp-custom-institution'); ?></p>
    <p><?php echo "Datum Entstehungskontext: " . usp_get_meta(false, 'usp-custom-datum'); ?></p>
    <p><?php echo "Breitengrad Ortsbezug: " . usp_get_meta(false, 'usp-custom-latitude'); ?></p>
    <p><?php echo "Längengrad Ortsbezug: " . usp_get_meta(false, 'usp-custom-longitude'); ?></p>
    <p><?php echo "Medienartefakt ID: " . usp_get_meta(false, 'usp-post-id'); ?></p>
    <p><?php
        $tags = get_the_tags();
        if ($tags) {
            echo 'Tags: ';
            foreach ($tags as $tag) {
                $tag_link = get_tag_link($tag->term_id);
                echo '<a href="' . esc_url($tag_link) . '">' . esc_html($tag->name) . '</a>, ';
            }
        }
        ?></p>
    <p><?php echo "Medienart: " . get_the_category($id)[0]->name . '</p>'; ?></p>
    <p><?php echo "URI: " . $permalink; ?></p>
    <p>Lizenz: Creative Commons - CC BY - Namensnennung 4.0 International</p>
    <p>&nbsp;</p>
    <p>&nbsp;</p>
</div>
<div class="metadaten">
    <b>Direktlink(s)</b><br>

    <p>
        <?php
        echo '<a href="' . esc_url($link) . '">' . esc_html($link) . '</a><br>';
        ?>

    </p>

    <p>
        <?php
        if (!empty($link_2)) {
            echo '<a href="' . esc_url($link_2) . '">' . esc_html($link_2) . '</a><br>';
        }

        if (!empty($link_3)) {
            echo '<a href="' . esc_url($link_3) . '">' . esc_html($link_3) . '</a><br>';
        }

        if (!empty($link_4)) {
            echo '<a href="' . esc_url($link_4) . '">' . esc_html($link_4) . '</a><br>';
        }
        ?>
    </p>
</div>

Dokumentation Dithering via CSS

In einer ersten Fassung wurde Medieneinbettungen ein Dithering-Effekt via CSS zugewiesen. Die oben als «Trennschicht» beschriebene Körnigkeit wurde hierfür als PNG/Base64 im mix-blend-mode: overlay eingebunden. Der Hash wurde zur Übersichtlichkeit dieser Seite im Code unten entfernt. Die Ebene wurde animiert, um den Effekt von genuinen Bildverunreinigungen der Medieninhalte abzuheben und die interpretative Wirkung der «Trennschicht» zu betonen.

body:after {
  animation: grain 5s steps(10) infinite;
  background-image: url(#);
  mix-blend-mode: overlay;
  content: "";
  height: 300%;
  left: -50%;
  opacity:.5;
  position: fixed;
  top: -110%;
  width: 300%;
  pointer-events:none;
}
@keyframes grain {
  0%, 100% { transform:translate(0, 0) }
  10% { transform:translate(-45%, -10%) }
  20% { transform:translate(-15%, 5%) }
  30% { transform:translate(7%, -25%) }
  40% { transform:translate(-5%, 25%) }
  50% { transform:translate(15%, 10%) }
  60% { transform:translate(15%, 0%) }
  70% { transform:translate(0%, 15%) }
  80% { transform:translate(3%, 35%) }
  90% { transform:translate(-10%, 10%) }
}

Es wurden zwei Muster (Raster und Filmkorn) ausprobiert. Die längste Zeit war das Muster auf der rechten Seite im Einsatz. Ein Testpublikum fand die so erreichte Darstellung allerdings zu unruhig. Der als zumutbar eruierte opacity Wert war mit 0.1 allerdings so gering, dass mittlerweile darauf verzichtet wird.

Dokumentation FAIR-Prinzipien, Linked Open Data und Ontologien

Defizite und Schlussbetrachtung

Recherche und Toolwahl

Die Entscheidung für WordPress bringt Vor- und Nachteile. Hiervon ist in allen folgenden Punkten die Rede. Grundsätzlich habe ich durch die gewählten Tools im Ansatz erreicht, was ich mir vorgenommen hatte. In puncto Toolwahl will ich aber vermerken, dass ich gegen Schluss der Arbeit auf eine weitere Systemlösung aufmerksam wurde. Die Museumsapplikation CollectiveAccess (Providence/ Pawtucket2) sieht zumindest so aus, als könnte sie eine ontologiebasierte – und somit FAIRere – Einpflegung der Daten bei gleichzeitiger visueller Gestaltungsfreiheit auch für Projekte mit wenig Ressourcen ermöglichen.

Georeferenzierung

Die räumliche Verortung der Einreichungen ist ein Hauptziel dieser Plattform. Zwei dafür wichtige Punkte konnten (noch) nicht realisiert werden. Zum einen ist die Darstellung via Google Maps im Vergleich zu dem selbsterstellten Kartenmaterial via Mapbox Tileset schade. Zusatzinformationen wie Höhenlinien oder Verwaltungsräume (Naturschutzgebiete etc.) können durch Google Maps momentan nicht mit einbezogen werden. Zum anderen birgt die aktuelle Lösung via JavaScript-Einbettung keine Möglichkeit, den Raumbezug anders als in einem einzigen Breiten- und Längengrad auszuweisen. Während eine sekundäre Verortung für jede Einreichung dabei technisch noch relativ einfach zu lösen wäre (eine zweite Karteneinbettung mit anderen Identifikatoren), ist eine ungenaue Verortung, etwa als Perimeter, Sphäre oder Linie mit Google Maps nicht möglich. Persönlich schätze ich den Verlust an Information hier gross ein, da eine Zuordnung an einen einzigen, präzisen Standort in den seltensten Fällen organisch sein wird.³² Ausnahme hiervon ist wohl der faktische Entstehungsort des Medienartefakts. Das Treweler-Plugin würde diese Unschärfen ermöglichen. Leider war die Umsetzung einer partizipativen Lösung nicht bis zur Abgabe möglich.

Ausblick

Mir schweben aktuell drei Erweiterungen mit Mehrwert vor. Zum einen soll ermöglicht werden, Einzelbeiträge, ganze Schlagwortsammlungen oder das gesamte Archiv als Data-Dump bereit zu stellen. Dies müsste ohne grössere Schwierigkeiten – zumindest als .csv-Export – zu lösen sein. Eventuell liessen sich sogar .zip-Pakete inklusive der Mediendateien automatisiert generieren.

Zum anderen fände ich die Beschäftigung mit dem Thema der Historizität wichtig und die Implementation eines Zeitstrahls interessant. Hierzu müssten die Datenformate vom aktuellen String-Format in ein maschinenlesbares Format übersetzt werden à la time.strptime und Ausnahmen (z.B. fehlende Tages- und Monatsangaben) gehandhabt werden. Anschliessend läge eine Datengrundlage vor, die sich auf die eine oder andere Weise als interaktiver Zeitstrahl darstellen lassen müsste. Eine Implementation auf Kartenbasis wäre technisch vermutlich anspruchsvoll.

Schliesslich und zuletzt bleibt die bereits angesprochene Überarbeitung der Datenstruktur hin zu einem triple-basierten Format ein Desiderat. Wie dies partizipativ zu machen wäre, kann ich zum jetzigen Zeitpunkt nicht beantworten. Würde es allerdings gelingen, läge mit WordPress in meinen Augen auch für gewisse Archivanwendungen ein System mit grosser Community, schlankem Code und schier endloser Erweiterungsmöglichkeit vor.

Als abschliessende Bemerkung dieses Ausblicks sei ein letztes Mal darauf verwiesen, dass es sich bei dem vorliegenden Prototypen um genau das handelt: ein unfertiges Experiment. Eine Veröffentlichung des Projekts mit der effektiven Absicht der Sammlungstätigkeit bedürfte vorderhand Antworten auf zentrale Fragestellungen, wie z.B. Datenschutz, Inhaltskontrolle, Haftungsfragen, Moderation, Beteiligungsmöglichkeiten über das Einreichen hinaus etc.).

Fussnoten

Impressum

Maximilian Lederer

maximilian.lederer@students.unibe.ch