https://filmstandards.org/difzf/api.php?action=feedcontributions&feedformat=atom&user=Dbalzer 2026-08-27T00:58:12Z Benutzerbeiträge MediaWiki 1.31.7 https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-28&diff=1693 2026-08-25T20:41:49Z

<p>Dbalzer: /* URIs für unselbstständiuge Entitäten */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 28. August 2026 ==<br /> <br /> === Eine Handvoll RDF-Themen: ===<br /> <br /> ==== Gattungen ====<br /> Ist dieses Vokabular hier irgendwie nachnutzbar? Leider funktioniert das Aufrufen der URIs auch nicht wirklich, weil etwas in XTree falsch konfiguriert ist. https://xtree-public.digicult-verbund.de/vocnet/?uriVocItem=http://filmportal.vocnet.org/category/&amp;startNode=c00061&amp;lang=de&amp;d=n <br /> <br /> ==== Geografika ====<br /> Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?<br /> <br /> Ein paar Überlegungen dazu sind hier schon notiert: [[Geografika in RDF]]<br /> <br /> ==== Ranges und Domains ====<br /> Jetzt, wo wir die Vokabulare aus pdf.term und pdf.reldef in SKOS formuliert und ausgelagert haben, stellt sich mir die Frage nach der Verwendung von rdfs:range/rdfs:domain. <br /> In den Vokabular-Definitionen fallen Domain/Range komplett raus, weil es dort ja um skos:Concepts geht und nicht um Properties. Ich habe die bestehenden Aussagen durch zdbvoc:domain/zdbvoc:range geändert, damit die Info erstmal nicht verloren geht. Wenn wir das beibehalten wollen, müssen wir die Properties noch definieren.<br /> <br /> In der Ontologie-Definition steht bei den Properties, welche in unserem RDF-Ausdruck der ZDB-Daten zu den o.g. Vokabularen führen, jetzt zdbvoc:term<br /> zdb:hatGattung a owl:ObjectProperty ;<br /> rdfs:label &quot;hat Gattung&quot; ;<br /> rdfs:range zdbvoc:term ; # rdfs:Resource?<br /> rdfs:domain zdb:Filmwerk .<br /> Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss? <br /> Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage:<br /> zdb:inFunktion a owl:ObjectProperty ;<br /> rdfs:label &quot;in Funktion&quot; ;<br /> rdfs:range zdbvoc:rels ; # changed from zdbvoc:term <br /> rdfs:domain zdb:Beteiligung .<br /> Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?<br /> <br /> ==== zdbvoc:P1 / zdbvoc:P2 ====<br /> Müssen diese Properties in den Vokabular-Definitionen stehen, um diese in der ZDB nutzen zu können? Für den RDF-Ausdruck der ZDB werden sie ja nicht wirklich benötigt, weil die Werte mit u.a. zdb:inRolle, zdb:genanntAls modelliert werden.<br /> <br /> ''DB: Stimmt. In der RDF-Darstellung sollten diese Properties so heißen, wie sie in 'reldef' für den jeweiligen Kontext definiert sind. Die Übersetzng aus der ZDB-Tabelle 'relation' wird dann beim RDF-Export erledigt.''<br /> <br /> ==== Entitäten-URIs ====<br /> Wir möchten gerne URIs à la ld.filmportal.de/4E097896FE814D858788B0FCC0FA3D89 für die Entitäten (außerhalb der Vokabulare) verwenden – also eine Subdomain von filmportal.de (siehe: https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-07-10)<br /> Wir brauchen noch ein bisschen Nachhilfe, was das konkret für die Einrichtung dieser Subdomain bedeutet. Was müssen wir dafür mit Werk21 klären? Oder kann diese Subdomain unabhängig vom Drupal auf www.filmportal.de verwaltet werden?<br /> <br /> ''DB: Grundsätzlich gibt es zwei Möglichkeiten: ''<br /> <br /> ''(1) Filmportal-URI (https-URL) ist identisch für die Web-Darstellung in Portal und für die Linked-Data-Ressource. Unterschieden wird per Content Negotiation, zusätzlich vielleicht auch per Suffix (.json, .ttl u.a.). Werk21 müsste dafür ein Stückchen Resolver-Code in ihren Webserver einfügen (der Code kann von uns kommen). ''<br /> <br /> ''(2) Alle RDF-Ressourcen werden über eine Subdomain wie ld.filmportal.de geliefert. Auch da würden wir einen Resolver mit Content Negotiation und eventuell Suffix-Erkennung verwenden, um die gewünschte RDF-Serialisierung zu aktivieren.''<br /> <br /> ==== „Hat …-Typ“-Properties ====<br /> Wir haben jetzt mehrere Properties, die die eine Instanz mit ihrem Typ aus dem Typenvokabular verbinden: zdb:hatTitelTyp, zdb:hatManifestationstyp, zdb:hatAuffuehrungsTyp, zdb:hatPruefungsTyp. Ist stattdessen auch eine generellere Property zdb:hatTyp denkbar? Ich habe sie testweise in Version 0.4.1 modelliert.<br /> <br /> ''DB: die differenzierten Properties soll(t)en die Restriktion auf das zulässige Teilvokabular ausdrücken. Wenn wir SHACL zur Konformiätsprüfung einsetzen, dann können wir den konkret zulässigen Typ anhand des Aussagesubjekts bestimmen; damit müsste zdb:hatTyp ausreichen. ''<br /> <br /> ==== Mapping ====<br /> Ich habe vor einigen Jahren Mal RML / RML Mapper für das Generieren von Linked Data ausprobiert. Damals war das nicht so erfolgreich, weil die Ausgangsdatei ein XML war und xSLT am Ende besser funktioniert hat. Aber RML schien mir auf Tabellen als Ausgangsformat ausgelegt zu sein. Vielleicht interessant für uns? https://rml.io/specs/rml/ https://www.w3.org/TR/r2rml/<br /> <br /> ==== URIs für unselbstständiuge Entitäten ====<br /> <br /> Im Filmwerk-Entwurf von DB sind nur die UIDs für Entitäten Filmwerk, Person und Körperschaft als Filmportal-URIs dargestellt. Alles Andere ist mit einem Blank-Node-Prefix versehen, also nicht als eigene Ressource referenzierbar. <br /> <br /> Der Entwurf von KR stellt alle UIDs der ZDB unter den öffentlichen Namensraum (fpde:). Damit wären auch unselbstständige Entitäten wie Aufführung, Manifestation, etc. als RDF-Ressource aus der LD-Sphäre abrufbar.<br /> <br /> Lassen sich Nachteile für den Entwurf von KR finden? (DB vermutet: nein)<br /> <br /> ==== IDTitel versus Titel ====<br /> <br /> Im Ontologie-Entwurf 0.4.1 ist die Property IDTitel entfernt worden; im Filmwerk-Entwurf IDTitel durch hatTitel ersetzt. Im ZDB-Datenmodell ist IDTitel absichtlich nicht als Instanz von Filmtitel modelliert, weil es hier als direkte, menschenlesbare Bezeichnung für das Filmwerk dient. Es ist ein einfacher String-Wert ohne weitere Eigenschaften. Bei der Erfassung wird der IDTitel automatisch aus den eigentlichen Titelangaben generiert und erfüllt nur den Zweck, das Filmwerk für menschliche Leser ohne SQL-Joins (und künftig in SPARQL ohne Property Chains) identifizierbar zu machen.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Geografika_in_RDF&diff=1692 2026-08-24T21:37:05Z

<p>Dbalzer: /* URIs für ZDB-Ländercodes */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == URIs für ZDB-Ländercodes ==<br /> <br /> Für die ISO 3166-Ländercodes gibt es nach wie vor keinen offiziellen RDF-Namensraum (die ISO ist in jeder Hinsicht im 20. Jahrhundert steckengebieben. Immerhin erlaubt man jetzt gnädiger Weise die Verwendung der Kürzel, ohne die 159 sFr für den Standard bezahlt zu haben).<br /> <br /> Naheliegend wäre auch, sich bei den [https://d-nb.info/standards/vocab/gnd/geographic-area-code.html GND-Regionencodes] zu bedienen. <br /> <br /> Allerdings gibt es ZDB-[[Ländercodes]], für die in der GND keine Entsprechung existiert. Mögliche Lösungen wären:<br /> <br /> * GND GeographicAreaCode dort, wo eine Übereinstimmung existiert und GND-Geografikum für die übrigen Regionen.<br /> <br /> * ZDB-Ländercodes mit exakter Entsprechung zu ISO 3166 unter den ISO-Namensraum und die übrigen entweder<br /> # als GND-Geografikum für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://d-nb.info/gnd/35065-5 GND:35065-5])<br /> # als Wikidata-Item für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://www.wikidata.org/wiki/Q170361 WD:Q170361])<br /> <br /> * oder vollständig unter einen eigenen DFF-Vokabular-Namensraum, mit Mappings zu allen bekannten URIs aus anderen Namensräumen.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-28&diff=1691 2026-08-24T21:12:43Z

<p>Dbalzer: /* Mapping */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 28. August 2026 ==<br /> <br /> === Eine Handvoll RDF-Themen: ===<br /> <br /> ==== Gattungen ====<br /> Ist dieses Vokabular hier irgendwie nachnutzbar? Leider funktioniert das Aufrufen der URIs auch nicht wirklich, weil etwas in XTree falsch konfiguriert ist. https://xtree-public.digicult-verbund.de/vocnet/?uriVocItem=http://filmportal.vocnet.org/category/&amp;startNode=c00061&amp;lang=de&amp;d=n <br /> <br /> ==== Geografika ====<br /> Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?<br /> <br /> Ein paar Überlegungen dazu sind hier schon notiert: [[Geografika in RDF]]<br /> <br /> ==== Ranges und Domains ====<br /> Jetzt, wo wir die Vokabulare aus pdf.term und pdf.reldef in SKOS formuliert und ausgelagert haben, stellt sich mir die Frage nach der Verwendung von rdfs:range/rdfs:domain. <br /> In den Vokabular-Definitionen fallen Domain/Range komplett raus, weil es dort ja um skos:Concepts geht und nicht um Properties. Ich habe die bestehenden Aussagen durch zdbvoc:domain/zdbvoc:range geändert, damit die Info erstmal nicht verloren geht. Wenn wir das beibehalten wollen, müssen wir die Properties noch definieren.<br /> <br /> In der Ontologie-Definition steht bei den Properties, welche in unserem RDF-Ausdruck der ZDB-Daten zu den o.g. Vokabularen führen, jetzt zdbvoc:term<br /> zdb:hatGattung a owl:ObjectProperty ;<br /> rdfs:label &quot;hat Gattung&quot; ;<br /> rdfs:range zdbvoc:term ; # rdfs:Resource?<br /> rdfs:domain zdb:Filmwerk .<br /> Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss? <br /> Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage:<br /> zdb:inFunktion a owl:ObjectProperty ;<br /> rdfs:label &quot;in Funktion&quot; ;<br /> rdfs:range zdbvoc:rels ; # changed from zdbvoc:term <br /> rdfs:domain zdb:Beteiligung .<br /> Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?<br /> <br /> ==== zdbvoc:P1 / zdbvoc:P2 ====<br /> Müssen diese Properties in den Vokabular-Definitionen stehen, um diese in der ZDB nutzen zu können? Für den RDF-Ausdruck der ZDB werden sie ja nicht wirklich benötigt, weil die Werte mit u.a. zdb:inRolle, zdb:genanntAls modelliert werden.<br /> <br /> ''DB: Stimmt. In der RDF-Darstellung sollten diese Properties so heißen, wie sie in 'reldef' für den jeweiligen Kontext definiert sind. Die Übersetzng aus der ZDB-Tabelle 'relation' wird dann beim RDF-Export erledigt.''<br /> <br /> ==== Entitäten-URIs ====<br /> Wir möchten gerne URIs à la ld.filmportal.de/4E097896FE814D858788B0FCC0FA3D89 für die Entitäten (außerhalb der Vokabulare) verwenden – also eine Subdomain von filmportal.de (siehe: https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-07-10)<br /> Wir brauchen noch ein bisschen Nachhilfe, was das konkret für die Einrichtung dieser Subdomain bedeutet. Was müssen wir dafür mit Werk21 klären? Oder kann diese Subdomain unabhängig vom Drupal auf www.filmportal.de verwaltet werden?<br /> <br /> ''DB: Grundsätzlich gibt es zwei Möglichkeiten: ''<br /> <br /> ''(1) Filmportal-URI (https-URL) ist identisch für die Web-Darstellung in Portal und für die Linked-Data-Ressource. Unterschieden wird per Content Negotiation, zusätzlich vielleicht auch per Suffix (.json, .ttl u.a.). Werk21 müsste dafür ein Stückchen Resolver-Code in ihren Webserver einfügen (der Code kann von uns kommen). ''<br /> <br /> ''(2) Alle RDF-Ressourcen werden über eine Subdomain wie ld.filmportal.de geliefert. Auch da würden wir einen Resolver mit Content Negotiation und eventuell Suffix-Erkennung verwenden, um die gewünschte RDF-Serialisierung zu aktivieren.''<br /> <br /> ==== „Hat …-Typ“-Properties ====<br /> Wir haben jetzt mehrere Properties, die die eine Instanz mit ihrem Typ aus dem Typenvokabular verbinden: zdb:hatTitelTyp, zdb:hatManifestationstyp, zdb:hatAuffuehrungsTyp, zdb:hatPruefungsTyp. Ist stattdessen auch eine generellere Property zdb:hatTyp denkbar? Ich habe sie testweise in Version 0.4.1 modelliert.<br /> <br /> ''DB: die differenzierten Properties soll(t)en die Restriktion auf das zulässige Teilvokabular ausdrücken. Wenn wir SHACL zur Konformiätsprüfung einsetzen, dann können wir den konkret zulässigen Typ anhand des Aussagesubjekts bestimmen; damit müsste zdb:hatTyp ausreichen. ''<br /> <br /> ==== Mapping ====<br /> Ich habe vor einigen Jahren Mal RML / RML Mapper für das Generieren von Linked Data ausprobiert. Damals war das nicht so erfolgreich, weil die Ausgangsdatei ein XML war und xSLT am Ende besser funktioniert hat. Aber RML schien mir auf Tabellen als Ausgangsformat ausgelegt zu sein. Vielleicht interessant für uns? https://rml.io/specs/rml/ https://www.w3.org/TR/r2rml/<br /> <br /> ==== URIs für unselbstständiuge Entitäten ====<br /> <br /> Im Filmwerk-Entwurf von DB sind nur die UIDs für Entitäten Filmwerk, Person und Körperschaft als Filmportal-URIs dargestellt. Alles Andere ist mit einem Blank-Node-Prefix versehen, also nicht als eigene Ressource referenzierbar. <br /> <br /> Der Entwurf von KR stellt alle UIDs der ZDB unter den öffentlichen Namensraum (fpde:). Damit wären auch unselbstständige Entitäten wie Aufführung, Manifestation, etc. als RDF-Ressource aus der LD-Sphäre abrufbar.<br /> <br /> Lassen sich Nachteile für den Entwurf von KR finden? (DB vermutet: nein)</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-28&diff=1690 2026-08-24T20:43:10Z

<p>Dbalzer: /* zdbvoc:P1 / zdbvoc:P2 */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 28. August 2026 ==<br /> <br /> === Eine Handvoll RDF-Themen: ===<br /> <br /> ==== Gattungen ====<br /> Ist dieses Vokabular hier irgendwie nachnutzbar? Leider funktioniert das Aufrufen der URIs auch nicht wirklich, weil etwas in XTree falsch konfiguriert ist. https://xtree-public.digicult-verbund.de/vocnet/?uriVocItem=http://filmportal.vocnet.org/category/&amp;startNode=c00061&amp;lang=de&amp;d=n <br /> <br /> ==== Geografika ====<br /> Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?<br /> <br /> Ein paar Überlegungen dazu sind hier schon notiert: [[Geografika in RDF]]<br /> <br /> ==== Ranges und Domains ====<br /> Jetzt, wo wir die Vokabulare aus pdf.term und pdf.reldef in SKOS formuliert und ausgelagert haben, stellt sich mir die Frage nach der Verwendung von rdfs:range/rdfs:domain. <br /> In den Vokabular-Definitionen fallen Domain/Range komplett raus, weil es dort ja um skos:Concepts geht und nicht um Properties. Ich habe die bestehenden Aussagen durch zdbvoc:domain/zdbvoc:range geändert, damit die Info erstmal nicht verloren geht. Wenn wir das beibehalten wollen, müssen wir die Properties noch definieren.<br /> <br /> In der Ontologie-Definition steht bei den Properties, welche in unserem RDF-Ausdruck der ZDB-Daten zu den o.g. Vokabularen führen, jetzt zdbvoc:term<br /> zdb:hatGattung a owl:ObjectProperty ;<br /> rdfs:label &quot;hat Gattung&quot; ;<br /> rdfs:range zdbvoc:term ; # rdfs:Resource?<br /> rdfs:domain zdb:Filmwerk .<br /> Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss? <br /> Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage:<br /> zdb:inFunktion a owl:ObjectProperty ;<br /> rdfs:label &quot;in Funktion&quot; ;<br /> rdfs:range zdbvoc:rels ; # changed from zdbvoc:term <br /> rdfs:domain zdb:Beteiligung .<br /> Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?<br /> <br /> ==== zdbvoc:P1 / zdbvoc:P2 ====<br /> Müssen diese Properties in den Vokabular-Definitionen stehen, um diese in der ZDB nutzen zu können? Für den RDF-Ausdruck der ZDB werden sie ja nicht wirklich benötigt, weil die Werte mit u.a. zdb:inRolle, zdb:genanntAls modelliert werden.<br /> <br /> ''DB: Stimmt. In der RDF-Darstellung sollten diese Properties so heißen, wie sie in 'reldef' für den jeweiligen Kontext definiert sind. Die Übersetzng aus der ZDB-Tabelle 'relation' wird dann beim RDF-Export erledigt.''<br /> <br /> ==== Entitäten-URIs ====<br /> Wir möchten gerne URIs à la ld.filmportal.de/4E097896FE814D858788B0FCC0FA3D89 für die Entitäten (außerhalb der Vokabulare) verwenden – also eine Subdomain von filmportal.de (siehe: https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-07-10)<br /> Wir brauchen noch ein bisschen Nachhilfe, was das konkret für die Einrichtung dieser Subdomain bedeutet. Was müssen wir dafür mit Werk21 klären? Oder kann diese Subdomain unabhängig vom Drupal auf www.filmportal.de verwaltet werden?<br /> <br /> ''DB: Grundsätzlich gibt es zwei Möglichkeiten: ''<br /> <br /> ''(1) Filmportal-URI (https-URL) ist identisch für die Web-Darstellung in Portal und für die Linked-Data-Ressource. Unterschieden wird per Content Negotiation, zusätzlich vielleicht auch per Suffix (.json, .ttl u.a.). Werk21 müsste dafür ein Stückchen Resolver-Code in ihren Webserver einfügen (der Code kann von uns kommen). ''<br /> <br /> ''(2) Alle RDF-Ressourcen werden über eine Subdomain wie ld.filmportal.de geliefert. Auch da würden wir einen Resolver mit Content Negotiation und eventuell Suffix-Erkennung verwenden, um die gewünschte RDF-Serialisierung zu aktivieren.''<br /> <br /> ==== „Hat …-Typ“-Properties ====<br /> Wir haben jetzt mehrere Properties, die die eine Instanz mit ihrem Typ aus dem Typenvokabular verbinden: zdb:hatTitelTyp, zdb:hatManifestationstyp, zdb:hatAuffuehrungsTyp, zdb:hatPruefungsTyp. Ist stattdessen auch eine generellere Property zdb:hatTyp denkbar? Ich habe sie testweise in Version 0.4.1 modelliert.<br /> <br /> ''DB: die differenzierten Properties soll(t)en die Restriktion auf das zulässige Teilvokabular ausdrücken. Wenn wir SHACL zur Konformiätsprüfung einsetzen, dann können wir den konkret zulässigen Typ anhand des Aussagesubjekts bestimmen; damit müsste zdb:hatTyp ausreichen. ''<br /> <br /> ==== Mapping ====<br /> Ich habe vor einigen Jahren Mal RML / RML Mapper für das Generieren von Linked Data ausprobiert. Damals war das nicht so erfolgreich, weil die Ausgangsdatei ein XML war und xSLT am Ende besser funktioniert hat. Aber RML schien mir auf Tabellen als Ausgangsformat ausgelegt zu sein. Vielleicht interessant für uns? https://rml.io/specs/rml/ https://www.w3.org/TR/r2rml/</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-28&diff=1689 2026-08-24T20:37:34Z

<p>Dbalzer: /* Geografika */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 28. August 2026 ==<br /> <br /> === Eine Handvoll RDF-Themen: ===<br /> <br /> ==== Gattungen ====<br /> Ist dieses Vokabular hier irgendwie nachnutzbar? Leider funktioniert das Aufrufen der URIs auch nicht wirklich, weil etwas in XTree falsch konfiguriert ist. https://xtree-public.digicult-verbund.de/vocnet/?uriVocItem=http://filmportal.vocnet.org/category/&amp;startNode=c00061&amp;lang=de&amp;d=n <br /> <br /> ==== Geografika ====<br /> Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?<br /> <br /> Ein paar Überlegungen dazu sind hier schon notiert: [[Geografika in RDF]]<br /> <br /> ==== Ranges und Domains ====<br /> Jetzt, wo wir die Vokabulare aus pdf.term und pdf.reldef in SKOS formuliert und ausgelagert haben, stellt sich mir die Frage nach der Verwendung von rdfs:range/rdfs:domain. <br /> In den Vokabular-Definitionen fallen Domain/Range komplett raus, weil es dort ja um skos:Concepts geht und nicht um Properties. Ich habe die bestehenden Aussagen durch zdbvoc:domain/zdbvoc:range geändert, damit die Info erstmal nicht verloren geht. Wenn wir das beibehalten wollen, müssen wir die Properties noch definieren.<br /> <br /> In der Ontologie-Definition steht bei den Properties, welche in unserem RDF-Ausdruck der ZDB-Daten zu den o.g. Vokabularen führen, jetzt zdbvoc:term<br /> zdb:hatGattung a owl:ObjectProperty ;<br /> rdfs:label &quot;hat Gattung&quot; ;<br /> rdfs:range zdbvoc:term ; # rdfs:Resource?<br /> rdfs:domain zdb:Filmwerk .<br /> Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss? <br /> Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage:<br /> zdb:inFunktion a owl:ObjectProperty ;<br /> rdfs:label &quot;in Funktion&quot; ;<br /> rdfs:range zdbvoc:rels ; # changed from zdbvoc:term <br /> rdfs:domain zdb:Beteiligung .<br /> Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?<br /> <br /> ==== zdbvoc:P1 / zdbvoc:P2 ====<br /> Müssen diese Properties in den Vokabular-Definitionen stehen, um diese in der ZDB nutzen zu können? Für den RDF-Ausdruck der ZDB werden sie ja nicht wirklich benötigt, weil die Werte mit u.a. zdb:inRolle, zdb:genanntAls modelliert werden.<br /> <br /> ==== Entitäten-URIs ====<br /> Wir möchten gerne URIs à la ld.filmportal.de/4E097896FE814D858788B0FCC0FA3D89 für die Entitäten (außerhalb der Vokabulare) verwenden – also eine Subdomain von filmportal.de (siehe: https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-07-10)<br /> Wir brauchen noch ein bisschen Nachhilfe, was das konkret für die Einrichtung dieser Subdomain bedeutet. Was müssen wir dafür mit Werk21 klären? Oder kann diese Subdomain unabhängig vom Drupal auf www.filmportal.de verwaltet werden?<br /> <br /> ''DB: Grundsätzlich gibt es zwei Möglichkeiten: ''<br /> <br /> ''(1) Filmportal-URI (https-URL) ist identisch für die Web-Darstellung in Portal und für die Linked-Data-Ressource. Unterschieden wird per Content Negotiation, zusätzlich vielleicht auch per Suffix (.json, .ttl u.a.). Werk21 müsste dafür ein Stückchen Resolver-Code in ihren Webserver einfügen (der Code kann von uns kommen). ''<br /> <br /> ''(2) Alle RDF-Ressourcen werden über eine Subdomain wie ld.filmportal.de geliefert. Auch da würden wir einen Resolver mit Content Negotiation und eventuell Suffix-Erkennung verwenden, um die gewünschte RDF-Serialisierung zu aktivieren.''<br /> <br /> ==== „Hat …-Typ“-Properties ====<br /> Wir haben jetzt mehrere Properties, die die eine Instanz mit ihrem Typ aus dem Typenvokabular verbinden: zdb:hatTitelTyp, zdb:hatManifestationstyp, zdb:hatAuffuehrungsTyp, zdb:hatPruefungsTyp. Ist stattdessen auch eine generellere Property zdb:hatTyp denkbar? Ich habe sie testweise in Version 0.4.1 modelliert.<br /> <br /> ''DB: die differenzierten Properties soll(t)en die Restriktion auf das zulässige Teilvokabular ausdrücken. Wenn wir SHACL zur Konformiätsprüfung einsetzen, dann können wir den konkret zulässigen Typ anhand des Aussagesubjekts bestimmen; damit müsste zdb:hatTyp ausreichen. ''<br /> <br /> ==== Mapping ====<br /> Ich habe vor einigen Jahren Mal RML / RML Mapper für das Generieren von Linked Data ausprobiert. Damals war das nicht so erfolgreich, weil die Ausgangsdatei ein XML war und xSLT am Ende besser funktioniert hat. Aber RML schien mir auf Tabellen als Ausgangsformat ausgelegt zu sein. Vielleicht interessant für uns? https://rml.io/specs/rml/ https://www.w3.org/TR/r2rml/</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-28&diff=1688 2026-08-24T20:07:04Z

<p>Dbalzer: /* „Hat …-Typ“-Properties */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 28. August 2026 ==<br /> <br /> === Eine Handvoll RDF-Themen: ===<br /> <br /> ==== Gattungen ====<br /> Ist dieses Vokabular hier irgendwie nachnutzbar? Leider funktioniert das Aufrufen der URIs auch nicht wirklich, weil etwas in XTree falsch konfiguriert ist. https://xtree-public.digicult-verbund.de/vocnet/?uriVocItem=http://filmportal.vocnet.org/category/&amp;startNode=c00061&amp;lang=de&amp;d=n <br /> <br /> ==== Geografika ====<br /> Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?<br /> <br /> ==== Ranges und Domains ====<br /> Jetzt, wo wir die Vokabulare aus pdf.term und pdf.reldef in SKOS formuliert und ausgelagert haben, stellt sich mir die Frage nach der Verwendung von rdfs:range/rdfs:domain. <br /> In den Vokabular-Definitionen fallen Domain/Range komplett raus, weil es dort ja um skos:Concepts geht und nicht um Properties. Ich habe die bestehenden Aussagen durch zdbvoc:domain/zdbvoc:range geändert, damit die Info erstmal nicht verloren geht. Wenn wir das beibehalten wollen, müssen wir die Properties noch definieren.<br /> <br /> In der Ontologie-Definition steht bei den Properties, welche in unserem RDF-Ausdruck der ZDB-Daten zu den o.g. Vokabularen führen, jetzt zdbvoc:term<br /> zdb:hatGattung a owl:ObjectProperty ;<br /> rdfs:label &quot;hat Gattung&quot; ;<br /> rdfs:range zdbvoc:term ; # rdfs:Resource?<br /> rdfs:domain zdb:Filmwerk .<br /> Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss? <br /> Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage:<br /> zdb:inFunktion a owl:ObjectProperty ;<br /> rdfs:label &quot;in Funktion&quot; ;<br /> rdfs:range zdbvoc:rels ; # changed from zdbvoc:term <br /> rdfs:domain zdb:Beteiligung .<br /> Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?<br /> <br /> ==== zdbvoc:P1 / zdbvoc:P2 ====<br /> Müssen diese Properties in den Vokabular-Definitionen stehen, um diese in der ZDB nutzen zu können? Für den RDF-Ausdruck der ZDB werden sie ja nicht wirklich benötigt, weil die Werte mit u.a. zdb:inRolle, zdb:genanntAls modelliert werden.<br /> <br /> ==== Entitäten-URIs ====<br /> Wir möchten gerne URIs à la ld.filmportal.de/4E097896FE814D858788B0FCC0FA3D89 für die Entitäten (außerhalb der Vokabulare) verwenden – also eine Subdomain von filmportal.de (siehe: https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-07-10)<br /> Wir brauchen noch ein bisschen Nachhilfe, was das konkret für die Einrichtung dieser Subdomain bedeutet. Was müssen wir dafür mit Werk21 klären? Oder kann diese Subdomain unabhängig vom Drupal auf www.filmportal.de verwaltet werden?<br /> <br /> ''DB: Grundsätzlich gibt es zwei Möglichkeiten: ''<br /> <br /> ''(1) Filmportal-URI (https-URL) ist identisch für die Web-Darstellung in Portal und für die Linked-Data-Ressource. Unterschieden wird per Content Negotiation, zusätzlich vielleicht auch per Suffix (.json, .ttl u.a.). Werk21 müsste dafür ein Stückchen Resolver-Code in ihren Webserver einfügen (der Code kann von uns kommen). ''<br /> <br /> ''(2) Alle RDF-Ressourcen werden über eine Subdomain wie ld.filmportal.de geliefert. Auch da würden wir einen Resolver mit Content Negotiation und eventuell Suffix-Erkennung verwenden, um die gewünschte RDF-Serialisierung zu aktivieren.''<br /> <br /> ==== „Hat …-Typ“-Properties ====<br /> Wir haben jetzt mehrere Properties, die die eine Instanz mit ihrem Typ aus dem Typenvokabular verbinden: zdb:hatTitelTyp, zdb:hatManifestationstyp, zdb:hatAuffuehrungsTyp, zdb:hatPruefungsTyp. Ist stattdessen auch eine generellere Property zdb:hatTyp denkbar? Ich habe sie testweise in Version 0.4.1 modelliert.<br /> <br /> ''DB: die differenzierten Properties soll(t)en die Restriktion auf das zulässige Teilvokabular ausdrücken. Wenn wir SHACL zur Konformiätsprüfung einsetzen, dann können wir den konkret zulässigen Typ anhand des Aussagesubjekts bestimmen; damit müsste zdb:hatTyp ausreichen. ''<br /> <br /> ==== Mapping ====<br /> Ich habe vor einigen Jahren Mal RML / RML Mapper für das Generieren von Linked Data ausprobiert. Damals war das nicht so erfolgreich, weil die Ausgangsdatei ein XML war und xSLT am Ende besser funktioniert hat. Aber RML schien mir auf Tabellen als Ausgangsformat ausgelegt zu sein. Vielleicht interessant für uns? https://rml.io/specs/rml/ https://www.w3.org/TR/r2rml/</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-28&diff=1687 2026-08-24T20:06:18Z

<p>Dbalzer: /* „Hat …-Typ“-Properties */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 28. August 2026 ==<br /> <br /> === Eine Handvoll RDF-Themen: ===<br /> <br /> ==== Gattungen ====<br /> Ist dieses Vokabular hier irgendwie nachnutzbar? Leider funktioniert das Aufrufen der URIs auch nicht wirklich, weil etwas in XTree falsch konfiguriert ist. https://xtree-public.digicult-verbund.de/vocnet/?uriVocItem=http://filmportal.vocnet.org/category/&amp;startNode=c00061&amp;lang=de&amp;d=n <br /> <br /> ==== Geografika ====<br /> Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?<br /> <br /> ==== Ranges und Domains ====<br /> Jetzt, wo wir die Vokabulare aus pdf.term und pdf.reldef in SKOS formuliert und ausgelagert haben, stellt sich mir die Frage nach der Verwendung von rdfs:range/rdfs:domain. <br /> In den Vokabular-Definitionen fallen Domain/Range komplett raus, weil es dort ja um skos:Concepts geht und nicht um Properties. Ich habe die bestehenden Aussagen durch zdbvoc:domain/zdbvoc:range geändert, damit die Info erstmal nicht verloren geht. Wenn wir das beibehalten wollen, müssen wir die Properties noch definieren.<br /> <br /> In der Ontologie-Definition steht bei den Properties, welche in unserem RDF-Ausdruck der ZDB-Daten zu den o.g. Vokabularen führen, jetzt zdbvoc:term<br /> zdb:hatGattung a owl:ObjectProperty ;<br /> rdfs:label &quot;hat Gattung&quot; ;<br /> rdfs:range zdbvoc:term ; # rdfs:Resource?<br /> rdfs:domain zdb:Filmwerk .<br /> Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss? <br /> Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage:<br /> zdb:inFunktion a owl:ObjectProperty ;<br /> rdfs:label &quot;in Funktion&quot; ;<br /> rdfs:range zdbvoc:rels ; # changed from zdbvoc:term <br /> rdfs:domain zdb:Beteiligung .<br /> Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?<br /> <br /> ==== zdbvoc:P1 / zdbvoc:P2 ====<br /> Müssen diese Properties in den Vokabular-Definitionen stehen, um diese in der ZDB nutzen zu können? Für den RDF-Ausdruck der ZDB werden sie ja nicht wirklich benötigt, weil die Werte mit u.a. zdb:inRolle, zdb:genanntAls modelliert werden.<br /> <br /> ==== Entitäten-URIs ====<br /> Wir möchten gerne URIs à la ld.filmportal.de/4E097896FE814D858788B0FCC0FA3D89 für die Entitäten (außerhalb der Vokabulare) verwenden – also eine Subdomain von filmportal.de (siehe: https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-07-10)<br /> Wir brauchen noch ein bisschen Nachhilfe, was das konkret für die Einrichtung dieser Subdomain bedeutet. Was müssen wir dafür mit Werk21 klären? Oder kann diese Subdomain unabhängig vom Drupal auf www.filmportal.de verwaltet werden?<br /> <br /> ''DB: Grundsätzlich gibt es zwei Möglichkeiten: ''<br /> <br /> ''(1) Filmportal-URI (https-URL) ist identisch für die Web-Darstellung in Portal und für die Linked-Data-Ressource. Unterschieden wird per Content Negotiation, zusätzlich vielleicht auch per Suffix (.json, .ttl u.a.). Werk21 müsste dafür ein Stückchen Resolver-Code in ihren Webserver einfügen (der Code kann von uns kommen). ''<br /> <br /> ''(2) Alle RDF-Ressourcen werden über eine Subdomain wie ld.filmportal.de geliefert. Auch da würden wir einen Resolver mit Content Negotiation und eventuell Suffix-Erkennung verwenden, um die gewünschte RDF-Serialisierung zu aktivieren.''<br /> <br /> ==== „Hat …-Typ“-Properties ====<br /> Wir haben jetzt mehrere Properties, die die eine Instanz mit ihrem Typ aus dem Typenvokabular verbinden: zdb:hatTitelTyp, zdb:hatManifestationstyp, zdb:hatAuffuehrungsTyp, zdb:hatPruefungsTyp. Ist stattdessen auch eine generellere Property zdb:hatTyp denkbar? Ich habe sie testweise in Version 0.4.1 modelliert.<br /> <br /> ''DB: die differenzierten Properties soll(t)en für Restriktion auf das zulässige Teilvokabular ausdrücken. Wenn wir SHACL zur Konformiätsprüfung einsetzen, dann können wir den konkret zulässigen Typ anhand des Aussagesubjekts bestimmen; damit müsste zdb:hatTyp ausreichen. ''<br /> <br /> ==== Mapping ====<br /> Ich habe vor einigen Jahren Mal RML / RML Mapper für das Generieren von Linked Data ausprobiert. Damals war das nicht so erfolgreich, weil die Ausgangsdatei ein XML war und xSLT am Ende besser funktioniert hat. Aber RML schien mir auf Tabellen als Ausgangsformat ausgelegt zu sein. Vielleicht interessant für uns? https://rml.io/specs/rml/ https://www.w3.org/TR/r2rml/</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-28&diff=1686 2026-08-24T19:57:57Z

<p>Dbalzer: /* Entitäten-URIs */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 28. August 2026 ==<br /> <br /> === Eine Handvoll RDF-Themen: ===<br /> <br /> ==== Gattungen ====<br /> Ist dieses Vokabular hier irgendwie nachnutzbar? Leider funktioniert das Aufrufen der URIs auch nicht wirklich, weil etwas in XTree falsch konfiguriert ist. https://xtree-public.digicult-verbund.de/vocnet/?uriVocItem=http://filmportal.vocnet.org/category/&amp;startNode=c00061&amp;lang=de&amp;d=n <br /> <br /> ==== Geografika ====<br /> Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?<br /> <br /> ==== Ranges und Domains ====<br /> Jetzt, wo wir die Vokabulare aus pdf.term und pdf.reldef in SKOS formuliert und ausgelagert haben, stellt sich mir die Frage nach der Verwendung von rdfs:range/rdfs:domain. <br /> In den Vokabular-Definitionen fallen Domain/Range komplett raus, weil es dort ja um skos:Concepts geht und nicht um Properties. Ich habe die bestehenden Aussagen durch zdbvoc:domain/zdbvoc:range geändert, damit die Info erstmal nicht verloren geht. Wenn wir das beibehalten wollen, müssen wir die Properties noch definieren.<br /> <br /> In der Ontologie-Definition steht bei den Properties, welche in unserem RDF-Ausdruck der ZDB-Daten zu den o.g. Vokabularen führen, jetzt zdbvoc:term<br /> zdb:hatGattung a owl:ObjectProperty ;<br /> rdfs:label &quot;hat Gattung&quot; ;<br /> rdfs:range zdbvoc:term ; # rdfs:Resource?<br /> rdfs:domain zdb:Filmwerk .<br /> Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss? <br /> Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage:<br /> zdb:inFunktion a owl:ObjectProperty ;<br /> rdfs:label &quot;in Funktion&quot; ;<br /> rdfs:range zdbvoc:rels ; # changed from zdbvoc:term <br /> rdfs:domain zdb:Beteiligung .<br /> Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?<br /> <br /> ==== zdbvoc:P1 / zdbvoc:P2 ====<br /> Müssen diese Properties in den Vokabular-Definitionen stehen, um diese in der ZDB nutzen zu können? Für den RDF-Ausdruck der ZDB werden sie ja nicht wirklich benötigt, weil die Werte mit u.a. zdb:inRolle, zdb:genanntAls modelliert werden.<br /> <br /> ==== Entitäten-URIs ====<br /> Wir möchten gerne URIs à la ld.filmportal.de/4E097896FE814D858788B0FCC0FA3D89 für die Entitäten (außerhalb der Vokabulare) verwenden – also eine Subdomain von filmportal.de (siehe: https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-07-10)<br /> Wir brauchen noch ein bisschen Nachhilfe, was das konkret für die Einrichtung dieser Subdomain bedeutet. Was müssen wir dafür mit Werk21 klären? Oder kann diese Subdomain unabhängig vom Drupal auf www.filmportal.de verwaltet werden?<br /> <br /> ''DB: Grundsätzlich gibt es zwei Möglichkeiten: ''<br /> <br /> ''(1) Filmportal-URI (https-URL) ist identisch für die Web-Darstellung in Portal und für die Linked-Data-Ressource. Unterschieden wird per Content Negotiation, zusätzlich vielleicht auch per Suffix (.json, .ttl u.a.). Werk21 müsste dafür ein Stückchen Resolver-Code in ihren Webserver einfügen (der Code kann von uns kommen). ''<br /> <br /> ''(2) Alle RDF-Ressourcen werden über eine Subdomain wie ld.filmportal.de geliefert. Auch da würden wir einen Resolver mit Content Negotiation und eventuell Suffix-Erkennung verwenden, um die gewünschte RDF-Serialisierung zu aktivieren.''<br /> <br /> ==== „Hat …-Typ“-Properties ====<br /> Wir haben jetzt mehrere Properties, die die eine Instanz mit ihrem Typ aus dem Typenvokabular verbinden: zdb:hatTitelTyp, zdb:hatManifestationstyp, zdb:hatAuffuehrungsTyp, zdb:hatPruefungsTyp. Ist stattdessen auch eine generellere Property zdb:hatTyp denkbar? Ich habe sie testweise in Version 0.4.1 modelliert.<br /> <br /> ==== Mapping ====<br /> Ich habe vor einigen Jahren Mal RML / RML Mapper für das Generieren von Linked Data ausprobiert. Damals war das nicht so erfolgreich, weil die Ausgangsdatei ein XML war und xSLT am Ende besser funktioniert hat. Aber RML schien mir auf Tabellen als Ausgangsformat ausgelegt zu sein. Vielleicht interessant für uns? https://rml.io/specs/rml/ https://www.w3.org/TR/r2rml/</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Reformhaus&diff=1682 2026-08-17T13:22:23Z

<p>Dbalzer: </p> <hr /> <div>Fortlaufende Aktivitäten zur Anpassung und Weiterentwicklung der Filmografie-Datenbank und zugehöriger Datendienste des DFF<br /> <br /> === Telekonferenzen zu anstehenden Themen ===<br /> <br /> * '''[[Jour fixe 2026-08-28]]''' - Diskussionspunkte<br /> * [[Jour fixe 2026-08-07]] - Diskussionspunkte<br /> * [[Jour fixe 2026-07-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-05-29]] - Diskussionspunkte<br /> * [[Jour fixe 2026-05-08]] - Diskussionspunkte<br /> * [[Jour fixe 2026-04-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-03-06]] - Diskussionspunkte<br /> * [[Jour fixe 2026-02-06]] - Diskussionspunkte<br /> * [[Jour fixe 2026-01-09]] - Diskussionspunkte<br /> * [[Jour fixe 2025-12-05]] - Diskussionspunkte<br /> * [[Jour fixe 2025-11-07]] - Diskussionspunkte<br /> * ''[[Jour fixe 2025-10-10]]'' - vertagt<br /> * [[Jour fixe 2025-09-05]] - Diskussionspunkte<br /> * [[Jour fixe 2025-07-11]] - Diskussionspunkte<br /> * [[Jour fixe 2025-06-13]] - Diskussionspunkte<br /> * [[Jour fixe 2025-05-09]] - Diskussionspunkte<br /> * [[Jour fixe 2025-04-04]] - Diskussionspunkte<br /> * [[Jour fixe 2025-03-07]] - Diskussionspunkte<br /> * [[Jour fixe 2025-02-07]] - Diskussionspunkte zur Prioritäten-Findung<br /> <br /> === Laufendes ===<br /> <br /> * [[Migration filmstandards.org]] - Was auf einen neuen Server mitgenommen werden soll<br /> <br /> * [[Elementvokabulare]] - Neuorganisation als Linked Data-Ressource<br /> <br /> * [[Zeitangaben in RDF]] - Standard-konforme Darstellung für Linked Data<br /> <br /> * [[Geografika in RDF]] - URIs für Länder und Regionen<br /> <br /> * [[Ergänzung des Datenschemas]] - Neue Relatoren<br /> <br /> * [[Bereinigung des Datenschemas]] - Entfernen nicht (mehr) benötigter Entitäten und Relationen; Änderungen an Eigenschaften und Datentypen<br /> <br /> * [[Erweiterungswünsche]] für die ZDB-Bearbeitung</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-28&diff=1681 2026-08-17T13:21:49Z

<p>Dbalzer: /* Jour fixe, Freitag, 4. September 2026 */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 28. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-28&diff=1679 2026-08-17T13:20:39Z

<p>Dbalzer: Dbalzer verschob die Seite Jour fixe 2026-09-04 nach Jour fixe 2026-08-28: Terminänderung</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 4. September 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-09-04&diff=1680 2026-08-17T13:20:39Z

<p>Dbalzer: Dbalzer verschob die Seite Jour fixe 2026-09-04 nach Jour fixe 2026-08-28: Terminänderung</p> <hr /> <div>#WEITERLEITUNG [[Jour fixe 2026-08-28]]</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-28&diff=1678 2026-08-14T10:39:33Z

<p>Dbalzer: Die Seite wurde neu angelegt: „Eine Seite aus dem Reformhaus == Jour fixe, Freitag, 4. September 2026 == Themenwüsche bitte hier notieren.“</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 4. September 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Reformhaus&diff=1677 2026-08-14T10:38:35Z

<p>Dbalzer: /* Telekonferenzen zu anstehenden Themen */</p> <hr /> <div>Fortlaufende Aktivitäten zur Anpassung und Weiterentwicklung der Filmografie-Datenbank und zugehöriger Datendienste des DFF<br /> <br /> === Telekonferenzen zu anstehenden Themen ===<br /> <br /> * '''[[Jour fixe 2026-09-04]]''' - Diskussionspunkte<br /> * [[Jour fixe 2026-08-07]] - Diskussionspunkte<br /> * [[Jour fixe 2026-07-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-05-29]] - Diskussionspunkte<br /> * [[Jour fixe 2026-05-08]] - Diskussionspunkte<br /> * [[Jour fixe 2026-04-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-03-06]] - Diskussionspunkte<br /> * [[Jour fixe 2026-02-06]] - Diskussionspunkte<br /> * [[Jour fixe 2026-01-09]] - Diskussionspunkte<br /> * [[Jour fixe 2025-12-05]] - Diskussionspunkte<br /> * [[Jour fixe 2025-11-07]] - Diskussionspunkte<br /> * ''[[Jour fixe 2025-10-10]]'' - vertagt<br /> * [[Jour fixe 2025-09-05]] - Diskussionspunkte<br /> * [[Jour fixe 2025-07-11]] - Diskussionspunkte<br /> * [[Jour fixe 2025-06-13]] - Diskussionspunkte<br /> * [[Jour fixe 2025-05-09]] - Diskussionspunkte<br /> * [[Jour fixe 2025-04-04]] - Diskussionspunkte<br /> * [[Jour fixe 2025-03-07]] - Diskussionspunkte<br /> * [[Jour fixe 2025-02-07]] - Diskussionspunkte zur Prioritäten-Findung<br /> <br /> === Laufendes ===<br /> <br /> * [[Migration filmstandards.org]] - Was auf einen neuen Server mitgenommen werden soll<br /> <br /> * [[Elementvokabulare]] - Neuorganisation als Linked Data-Ressource<br /> <br /> * [[Zeitangaben in RDF]] - Standard-konforme Darstellung für Linked Data<br /> <br /> * [[Geografika in RDF]] - URIs für Länder und Regionen<br /> <br /> * [[Ergänzung des Datenschemas]] - Neue Relatoren<br /> <br /> * [[Bereinigung des Datenschemas]] - Entfernen nicht (mehr) benötigter Entitäten und Relationen; Änderungen an Eigenschaften und Datentypen<br /> <br /> * [[Erweiterungswünsche]] für die ZDB-Bearbeitung</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1672 2026-08-07T14:25:25Z

<p>Dbalzer: /* LD-Filmwerke */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt. <br /> <br /> ''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''<br /> <br /> ''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''<br /> <br /> === Linked Data ===<br /> <br /> In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)<br /> <br /> ''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''<br /> <br /> Bei mir sehen die IRIs mit Bindestrich in rels_Credits.trig im Syntax-Highlighting von VS Code etwas komisch aus. Machen die Probleme?<br /> <br /> ''DB: Nee, das liegt nur am Syntax-Highlighter, der ist nicht ganz auf dem aktuellen Stand.''<br /> <br /> ==== LD-Filmwerke ====<br /> <br /> Die Mehrzahl der Vokabulare aus den ZDB-Tabellen &quot;term&quot; und &quot;reldef&quot; sind so weit in RDF verfügbar (abgesehen von den ausstehenden domain/range-Änderungen, s.o., und noch fehlenden Vokabularen, v.a. aus der Tabelle &quot;region&quot;), dass wir exemplarische RDF-Darstellungen erster Filmwerke &quot;von Hand&quot; konstruieren können. Ein erster Versuch zur Diskussion ist mit der SPARQL-Anweisung<br /> <br /> DESCRIBE &lt;https://www.filmportal.de/4E097896FE814D858788B0FCC0FA3D89&gt; <br /> <br /> in https://ws.dff.film/ld-svc/sparql-ui/sparql.html zu bekommen. Die nächste größere Übung wird darin bestehen, Darstellungen für komplexere Filmwerke und schließlich auch für Aggregatwerke zu konstruieren.<br /> <br /> In der Ontologie ist &quot;Beteiligung&quot; keine Unterklasse von &quot;Ereignis&quot;. Das erscheint praktisch, aber etwas gegen die Intuition. Sollten wir das ändern oder in einer Definition begründen?<br /> <br /> ''Geklärt: Beteligung und Ereignis bleiben disjunkt.''<br /> <br /> === Tombstones ===<br /> <br /> Die wichtigste Frage hierbei ist, was in einem gelöschten Datensatz enthalten sein soll. Naheliegend wäre, einen Link zum &quot;Gewinner&quot;-Datensatz z.B. in filmwerk.Anmerkung zu schreiben. Zusätzlich bräuchte es ein Flag, mit dem dieser Datensatz sowohl ZDB-intern wie auch durch die filmportal-Suchfunktion von den aktiven Datensätzen unterschieden werden kann.<br /> <br /> Seitens filmportal.de werden die Anmerkungs-Felder bisher nicht ausgewertet. Das müsste geschehen, damit die Umlenkungen entweder als klickbarer Link oder als Redirect-Anweiseung an den Browser ausgegeben werden können.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1671 2026-08-07T07:53:21Z

<p>Dbalzer: /* LD-Filmwerke */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt. <br /> <br /> ''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''<br /> <br /> ''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''<br /> <br /> === Linked Data ===<br /> <br /> In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)<br /> <br /> ''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''<br /> <br /> Bei mir sehen die IRIs mit Bindestrich in rels_Credits.trig im Syntax-Highlighting von VS Code etwas komisch aus. Machen die Probleme?<br /> <br /> ''DB: Nee, das liegt nur am Syntax-Highlighter, der ist nicht ganz auf dem aktuellen Stand.''<br /> <br /> ==== LD-Filmwerke ====<br /> <br /> Die Mehrzahl der Vokabulare aus den ZDB-Tabellen &quot;term&quot; und &quot;reldef&quot; sind so weit in RDF verfügbar (abgesehen von den ausstehenden domain/range-Änderungen, s.o., und noch fehlenden Vokabularen, v.a. aus der Tabelle &quot;region&quot;), dass wir exemplarische RDF-Darstellungen erster Filmwerke &quot;von Hand&quot; konstruieren können. Ein erster Versuch zur Diskussion ist mit der SPARQL-Anweisung<br /> <br /> DESCRIBE &lt;https://www.filmportal.de/4E097896FE814D858788B0FCC0FA3D89&gt; <br /> <br /> in https://ws.dff.film/ld-svc/sparql-ui/sparql.html zu bekommen. Die nächste größere Übung wird darin bestehen, Darstellungen für komplexere Filmwerke und schließlich auch für Aggregatwerke zu konstruieren.<br /> <br /> In der Ontologie ist &quot;Beteiligung&quot; keine Unterklasse von &quot;Ereignis&quot;. Das erscheint praktisch, aber etwas gegen die Intuition. Sollten wir das ändern oder in einer Definition begründen?<br /> <br /> [[Datei:Dff-onto-beteiligung.png|300px]]<br /> <br /> === Tombstones ===<br /> <br /> Die wichtigste Frage hierbei ist, was in einem gelöschten Datensatz enthalten sein soll. Naheliegend wäre, einen Link zum &quot;Gewinner&quot;-Datensatz z.B. in filmwerk.Anmerkung zu schreiben. Zusätzlich bräuchte es ein Flag, mit dem dieser Datensatz sowohl ZDB-intern wie auch durch die filmportal-Suchfunktion von den aktiven Datensätzen unterschieden werden kann.<br /> <br /> Seitens filmportal.de werden die Anmerkungs-Felder bisher nicht ausgewertet. Das müsste geschehen, damit die Umlenkungen entweder als klickbarer Link oder als Redirect-Anweiseung an den Browser ausgegeben werden können.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Datei:Dff-onto-beteiligung.png&diff=1670 2026-08-07T07:49:39Z

<p>Dbalzer: DFF-ZDB-Ontologie Aussschnitt Skizze</p> <hr /> <div>== Beschreibung ==<br /> DFF-ZDB-Ontologie Aussschnitt Skizze</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1669 2026-08-07T07:30:33Z

<p>Dbalzer: /* Linked Data */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt. <br /> <br /> ''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''<br /> <br /> ''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''<br /> <br /> === Linked Data ===<br /> <br /> In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)<br /> <br /> ''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''<br /> <br /> Bei mir sehen die IRIs mit Bindestrich in rels_Credits.trig im Syntax-Highlighting von VS Code etwas komisch aus. Machen die Probleme?<br /> <br /> ''DB: Nee, das liegt nur am Syntax-Highlighter, der ist nicht ganz auf dem aktuellen Stand.''<br /> <br /> ==== LD-Filmwerke ====<br /> <br /> Die Mehrzahl der Vokabulare aus den ZDB-Tabellen &quot;term&quot; und &quot;reldef&quot; sind so weit in RDF verfügbar (abgesehen von den ausstehenden domain/range-Änderungen, s.o., und noch fehlenden Vokabularen, v.a. aus der Tabelle &quot;region&quot;), dass wir exemplarische RDF-Darstellungen erster Filmwerke &quot;von Hand&quot; konstruieren können. Ein erster Versuch zur Diskussion ist mit der SPARQL-Anweisung<br /> <br /> DESCRIBE &lt;https://www.filmportal.de/4E097896FE814D858788B0FCC0FA3D89&gt; <br /> <br /> in https://ws.dff.film/ld-svc/sparql-ui/sparql.html zu bekommen. Die nächste größere Übung wird darin bestehen, Darstellungen für komplexere Filmwerke und schließlich auch für Aggregatwerke zu konstruieren.<br /> <br /> In der Ontologie ist &quot;Beteiligung&quot; keine Unterklasse von &quot;Ereignis&quot;. Das erscheint praktisch, aber etwas gegen die Intuition. Sollten wir das ändern oder in einer Definition begründen?<br /> <br /> === Tombstones ===<br /> <br /> Die wichtigste Frage hierbei ist, was in einem gelöschten Datensatz enthalten sein soll. Naheliegend wäre, einen Link zum &quot;Gewinner&quot;-Datensatz z.B. in filmwerk.Anmerkung zu schreiben. Zusätzlich bräuchte es ein Flag, mit dem dieser Datensatz sowohl ZDB-intern wie auch durch die filmportal-Suchfunktion von den aktiven Datensätzen unterschieden werden kann.<br /> <br /> Seitens filmportal.de werden die Anmerkungs-Felder bisher nicht ausgewertet. Das müsste geschehen, damit die Umlenkungen entweder als klickbarer Link oder als Redirect-Anweiseung an den Browser ausgegeben werden können.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1666 2026-08-05T19:18:00Z

<p>Dbalzer: /* LD-Filmwerke */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt. <br /> <br /> ''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''<br /> <br /> ''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''<br /> <br /> === Linked Data ===<br /> <br /> In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)<br /> <br /> ''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''<br /> <br /> ==== LD-Filmwerke ====<br /> <br /> Die Mehrzahl der Vokabulare aus den ZDB-Tabellen &quot;term&quot; und &quot;reldef&quot; sind so weit in RDF verfügbar (abgesehen von den ausstehenden domain/range-Änderungen, s.o., und noch fehlenden Vokabularen, v.a. aus der Tabelle &quot;region&quot;), dass wir exemplarische RDF-Darstellungen erster Filmwerke &quot;von Hand&quot; konstruieren können. Ein erster Versuch zur Diskussion ist mit der SPARQL-Anweisung<br /> <br /> DESCRIBE &lt;https://www.filmportal.de/4E097896FE814D858788B0FCC0FA3D89&gt; <br /> <br /> in https://ws.dff.film/ld-svc/sparql-ui/sparql.html zu bekommen. Die nächste größere Übung wird darin bestehen, Darstellungen für komplexere Filmwerke und schließlich auch für Aggregatwerke zu konstruieren.<br /> <br /> === Tombstones ===<br /> <br /> Die wichtigste Frage hierbei ist, was in einem gelöschten Datensatz enthalten sein soll. Naheliegend wäre, einen Link zum &quot;Gewinner&quot;-Datensatz z.B. in filmwerk.Anmerkung zu schreiben. Zusätzlich bräuchte es ein Flag, mit dem dieser Datensatz sowohl ZDB-intern wie auch durch die filmportal-Suchfunktion von den aktiven Datensätzen unterschieden werden kann.<br /> <br /> Seitens filmportal.de werden die Anmerkungs-Felder bisher nicht ausgewertet. Das müsste geschehen, damit die Umlenkungen entweder als klickbarer Link oder als Redirect-Anweiseung an den Browser ausgegeben werden können.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1665 2026-08-05T19:12:03Z

<p>Dbalzer: /* LD-Filmwerke */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt. <br /> <br /> ''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''<br /> <br /> ''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''<br /> <br /> === Linked Data ===<br /> <br /> In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)<br /> <br /> ''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''<br /> <br /> ==== LD-Filmwerke ====<br /> <br /> Die Mehrzahl der Vokabulare aus den ZDB-Tabellen &quot;term&quot; und &quot;reldef&quot; sind so weit in RDF verfügbae (abgesehen von den ausstehenden domain/range-Änderungen, s.o., und noch einigen fehlenden Vokabularen), dass wir exemplarische RDF-Darstellungen erster Filmwerke &quot;von Hand&quot; konstruieren können. Ein erster Versuch zur Diskussion ist mit der SPARQL-Anweisung<br /> <br /> DESCRIBE &lt;https://www.filmportal.de/4E097896FE814D858788B0FCC0FA3D89&gt; <br /> <br /> in https://ws.dff.film/ld-svc/sparql-ui/sparql.html zu bekommen. Die nächste größere Übung wird darin bestehen, Darstellungen für komplexere Filmwerke und schließlich auch für Aggregatwerke zu konstruieren.<br /> <br /> === Tombstones ===<br /> <br /> Die wichtigste Frage hierbei ist, was in einem gelöschten Datensatz enthalten sein soll. Naheliegend wäre, einen Link zum &quot;Gewinner&quot;-Datensatz z.B. in filmwerk.Anmerkung zu schreiben. Zusätzlich bräuchte es ein Flag, mit dem dieser Datensatz sowohl ZDB-intern wie auch durch die filmportal-Suchfunktion von den aktiven Datensätzen unterschieden werden kann.<br /> <br /> Seitens filmportal.de werden die Anmerkungs-Felder bisher nicht ausgewertet. Das müsste geschehen, damit die Umlenkungen entweder als klickbarer Link oder als Redirect-Anweiseung an den Browser ausgegeben werden können.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1664 2026-08-05T19:07:22Z

<p>Dbalzer: /* Linked Data */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt. <br /> <br /> ''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''<br /> <br /> ''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''<br /> <br /> === Linked Data ===<br /> <br /> In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)<br /> <br /> ''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''<br /> <br /> ==== LD-Filmwerke ====<br /> <br /> Die Mehrzahl der Vokabulare aus den ZDB-Tabellen &quot;term&quot; und &quot;reldef&quot; sind so weit in RDF verfügbae (abgesehen von den ausstehenden domain/range-Änderungen, s.o., und noch einigen fehlenden Vokabularen), dass wir exemplarische RDF-Darstellungen erster Filmwerke &quot;von Hand&quot; konstruieren können. Ein erster Versuch zur Diskussion ist mit <br /> <br /> DESCRIBE &lt;https://www.filmportal.de/4E097896FE814D858788B0FCC0FA3D89&gt; <br /> <br /> im SPARQL-Interface https://ws.dff.film/ld-svc/sparql-ui/sparql.html zu bekommen. Die nächste größere Übung wird in komplexeren Filmwerken und in der Darstellung von Aggregatwerken bestehen.<br /> <br /> === Tombstones ===<br /> <br /> Die wichtigste Frage hierbei ist, was in einem gelöschten Datensatz enthalten sein soll. Naheliegend wäre, einen Link zum &quot;Gewinner&quot;-Datensatz z.B. in filmwerk.Anmerkung zu schreiben. Zusätzlich bräuchte es ein Flag, mit dem dieser Datensatz sowohl ZDB-intern wie auch durch die filmportal-Suchfunktion von den aktiven Datensätzen unterschieden werden kann.<br /> <br /> Seitens filmportal.de werden die Anmerkungs-Felder bisher nicht ausgewertet. Das müsste geschehen, damit die Umlenkungen entweder als klickbarer Link oder als Redirect-Anweiseung an den Browser ausgegeben werden können.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1663 2026-08-05T18:53:27Z

<p>Dbalzer: /* Linked Data */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt. <br /> <br /> ''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''<br /> <br /> ''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''<br /> <br /> === Linked Data ===<br /> <br /> In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)<br /> <br /> ''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''<br /> <br /> ==== LD-Filmwerke ====<br /> <br /> Die Mehrzahl der Vokabulare aus den ZDB-Tabellen &quot;term&quot; und &quot;reldef&quot; sind so weit in RDF verfügbae (abgesehen von den ausstehenden domain/range-Änderungen, s.o., und noch einigen fehlenden Vokabularen), dass wir exemplarische RDF-Darstellungen erster Filmwerke &quot;von Hand&quot; konstruieren können. Ein erster Versuch zur Diskussion ist mit <br /> <br /> DESCRIBE &lt;https://www.filmportal.de/4E097896FE814D858788B0FCC0FA3D89&gt; <br /> <br /> im SPARQL-Interface https://ws.dff.film/ld-svc/sparql-ui/sparql.html zu bekommen. Die nächste größere Übung wird in komplexeren Filmwerken und in der Darstellung von Aggregatwerken bestehen.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Geografika_in_RDF&diff=1662 2026-08-05T18:41:39Z

<p>Dbalzer: /* URIs für ZDB-Ländercodes */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == URIs für ZDB-Ländercodes ==<br /> <br /> Für die ISO 3166-Ländercodes gibt es nach wie vor keinen offiziellen RDF-Namensraum (die ISO ist in jeder Hinsicht im 20. Jahrhundert steckengebieben. Immerhin erlaubt man jetzt gnädiger Weise die Verwendung der Kürzel, ohne die 159 sFr für den Standard bezahlt zu haben).<br /> <br /> Naheliegend wäre auch, sich bei den [https://d-nb.info/standards/vocab/gnd/geographic-area-code.html GND-Regionencodes] zu bedienen. <br /> <br /> Allerdings gibt es ZDB-[[Ländercodes]], für die in der GND keine Entsprechung existiert. Mögliche Lösungen wären:<br /> <br /> * GND GeographicAreaCode dort, wo eine Übereinstimmung existiert und GND-Geografikum für die übrigen Regionen.<br /> <br /> * ZDB-Ländercodes mit exakter Entsprechung zu ISO 3166 unter den ISO-Namensraum und die übrigen entweder<br /> # als GND-Geografikum für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://d-nb.info/gnd/35065-5 GND:35065-5])<br /> # als Wikidata-Item für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://www.wikidata.org/wiki/Q170361 WD:Q170361])<br /> # oder vollständig unter einen eigenen DFF-Vokabular-Namensraum, mit Mappings zu allen bekannten URIs aus anderen Namensräumen.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1661 2026-08-05T18:32:27Z

<p>Dbalzer: /* Linked Data */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt. <br /> <br /> ''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''<br /> <br /> ''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''<br /> <br /> === Linked Data ===<br /> <br /> In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)<br /> <br /> ''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1660 2026-08-05T18:31:32Z

<p>Dbalzer: /* Migration filmstandards.org */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt. <br /> <br /> ''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''<br /> <br /> ''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''<br /> <br /> === Linked Data ===<br /> <br /> In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)<br /> <br /> ''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits tatsächlich zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1659 2026-08-05T18:27:34Z

<p>Dbalzer: </p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten.<br /> <br /> ''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''<br /> <br /> ''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''<br /> <br /> === Linked Data ===<br /> <br /> In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)<br /> <br /> ''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits tatsächlich zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1656 2026-08-03T19:28:48Z

<p>Dbalzer: /* Migration filmstandards.org */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1655 2026-08-03T06:38:58Z

<p>Dbalzer: /* Jour fixe, Freitag, 7. August 2026 */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Migration filmstandards.org ===<br /> <br /> Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu Liste auf [[Migration_filmstandards.org]] entschieden werden?<br /> <br /> Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-08-07&diff=1654 2026-08-03T06:29:15Z

<p>Dbalzer: Die Seite wurde neu angelegt: „Eine Seite aus dem Reformhaus == Jour fixe, Freitag, 7. August 2026 == Themenwüsche bitte hier notieren.“</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 7. August 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Reformhaus&diff=1653 2026-08-03T06:28:51Z

<p>Dbalzer: </p> <hr /> <div>Fortlaufende Aktivitäten zur Anpassung und Weiterentwicklung der Filmografie-Datenbank und zugehöriger Datendienste des DFF<br /> <br /> === Telekonferenzen zu anstehenden Themen ===<br /> <br /> * '''[[Jour fixe 2026-08-07]]''' - Diskussionspunkte<br /> * [[Jour fixe 2026-07-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-05-29]] - Diskussionspunkte<br /> * [[Jour fixe 2026-05-08]] - Diskussionspunkte<br /> * [[Jour fixe 2026-04-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-03-06]] - Diskussionspunkte<br /> * [[Jour fixe 2026-02-06]] - Diskussionspunkte<br /> * [[Jour fixe 2026-01-09]] - Diskussionspunkte<br /> * [[Jour fixe 2025-12-05]] - Diskussionspunkte<br /> * [[Jour fixe 2025-11-07]] - Diskussionspunkte<br /> * ''[[Jour fixe 2025-10-10]]'' - vertagt<br /> * [[Jour fixe 2025-09-05]] - Diskussionspunkte<br /> * [[Jour fixe 2025-07-11]] - Diskussionspunkte<br /> * [[Jour fixe 2025-06-13]] - Diskussionspunkte<br /> * [[Jour fixe 2025-05-09]] - Diskussionspunkte<br /> * [[Jour fixe 2025-04-04]] - Diskussionspunkte<br /> * [[Jour fixe 2025-03-07]] - Diskussionspunkte<br /> * [[Jour fixe 2025-02-07]] - Diskussionspunkte zur Prioritäten-Findung<br /> <br /> === Laufendes ===<br /> <br /> * [[Migration filmstandards.org]] - Was auf einen neuen Server mitgenommen werden soll<br /> <br /> * [[Elementvokabulare]] - Neuorganisation als Linked Data-Ressource<br /> <br /> * [[Zeitangaben in RDF]] - Standard-konforme Darstellung für Linked Data<br /> <br /> * [[Geografika in RDF]] - URIs für Länder und Regionen<br /> <br /> * [[Ergänzung des Datenschemas]] - Neue Relatoren<br /> <br /> * [[Bereinigung des Datenschemas]] - Entfernen nicht (mehr) benötigter Entitäten und Relationen; Änderungen an Eigenschaften und Datentypen<br /> <br /> * [[Erweiterungswünsche]] für die ZDB-Bearbeitung</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1652 2026-07-21T14:57:58Z

<p>Dbalzer: /* Verwendungskontexte */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Plan ==<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === Relations-Kontexte ===<br /> <br /> Im ZDB-Modell wird zwischen zwei Arten von Vokabularen unterschieden: <br /> <br /> * die Tabelle &quot;reldef&quot; definiert Beziehungen der Form m:n (''many-to-many''). die in der Tabelle &quot;relation&quot; für Aussagen zu Beziehungen zwischen jeweils zwei Entitäten verwednet werden. In OWL entpricht dies dem Typ ObjectProperty.<br /> <br /> * Tabelle &quot;term&quot; definiert Beziehungen der Formen 1:n und 1:1, die als Aussagen zu verschiedenen Eigenschaften einer Entität verwendet werden. In OWL entspricht die Form 1:n dem Typ DatatypeProperty und die Form 1:1 dem Typ FunctionalProperty.<br /> <br /> Der wichtigste Unterschied ist hierbei, dass es sich bei der n:m-Relation (ObjectProperty) auf beiden Seiten (Subjekt und Objekt) um Instanzen vollwertiger Entitäten handelt, während dies bei der 1:n und der 1:1-Relation nur für das Subjekt gilt. Das Objekt ist hier lediglich ein Begriff, also ein Abstraktum, das dem Subjekt als Typus zugeordnet wird.<br /> <br /> In 1:n-Beziehungen kann es mehrere Aussagen zu einer Eigenschaft geben, beispielsweise kann eine Instanz von &quot;Person&quot; mehr als eine charakteristische Tätigkeit haben. Die 1:1-Beziehung erlaubt dagegen keine mehrfachen Eigenschaftsaussagen, so ist beispielsweise für eine Instanz von &quot;Aufführung&quot; nur eine einzige Aussage zum Aufführungstyp zugelassen.<br /> <br /> === Organisation der Vokabulare ===<br /> <br /> skos:Concept<br /> <br /> Jedes Vokabularelement der DFF-ZDB wird, entprechend einer weit verbreiteten Konvention, als eine Instanz der Klasse skos:Concept definiert. Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben. <br /> <br /> skos:ConceptGroup<br /> <br /> skos:ConceptScheme<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung müssen auch Anwendungs-Restriktionen berücksichtigt werden: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL) und die Eigenschaftsvokabulare für Ereignisse usw. <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> Dies würde bei Abfragen das Auswerten der Umkehrbeziehung von skos:member ersparen und insgesamt wohl auch einfacher zu pflegen sein.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher definiert und in Gebrauch sind für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, vorhandene ZDB-Datenelemente als eigene Properties zu definieren:<br /> <br /> voccredit:Animation<br /> a skos:Concept ;<br /> zdbvoc:P1 &quot;unter Namen&quot; ;<br /> zdbvoc:P2 &quot;Detail&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.<br /> <br /> == Diskussion ==<br /> <br /> * KR: Ich hatte bei der RDF-Version der ZDB-Daten immer insbesondere externe Nutzer und Nutzerinnen vor Augen. Diese benötigen Informationen/Properties wie skos:notation mit dem Rang des Credits, zdbvoc:P1 und zdbvoc:P2 mit Informationen zur Darstellung in Benutzeroberflächen ja gar nicht, oder? Vielleicht können wir hier noch etwas reduzieren. Die Reihenfolge von Credits, im Sinne der Nennung im Abspann, könnte man ja eher noch als weitere Property von zdb:Beteiligung modellieren?<br /> ** DB: Wenn wir Properties für P1/P2 und dergleichen rauslassen, brauchen wir einen anderen Ort dafür. Der Vorteil, alle für die ZDB-Bearbeitung nötigen Deklarationen mit einer RDF-Abfrage zu bekommen, wäre dann nicht mehr gegeben. Solche &quot;betriebsinternen&quot; Properties sind keineswegs unüblich und externe Nutzung beschränkt sich ohnehin auf das, was benötigt wird. Vokabular-APIs können darüber hinaus auch mit Profilen (short/standard/full oder so) versehen werden.<br /> <br /> * KR: Bei Vokabularen, in denen wir Hierarchien haben (z.B. Aufführungsart) könnte man in einem weiteren Schritt aber noch mit skos:broader und skos:narrower arbeiten, richtig? Im letzten Treffen hattest du große Einwände, aber ich glaube, das Bezog sich auf skos:ConceptSchemes?<br /> ** Die Beziehung zwischen Gruppierung und Tätigkeit folgt nicht der Definition für logische Hierarchiebeziehungen, wie von SKOS für broader/narrower gefordert (&quot;Schnitt&quot; IsA &quot;Schnitt&quot;, &quot;Licht&quot; IsA &quot;Kamera&quot; usw. sind logisch nicht haltbare Aussagen). Außerdem werden die Gruppenbezeichner nicht als Relatoren verwendet, sondern dienen nur dem Arrangement an Benutzeroberflächen. Externe Anwendungen können Credits umgruppieren, ohne dass sich die eigentliche Aussage ändert. Für Grupperungen jenseits logischer Hierarchien sieht SKOS ausdrücklich das Collection-Element vor. <br /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<br /> <br /> * KR: Noch eine Verständnisfrage zum Verhältnis der ConceptSchemes (zdbvoc:auff_art, zdbvoc:credit und zdbvoc:fmtype) zu den jeweiligen Ontologie-Klassen zdb:Veroeffentlichung, zdb:Funktion und zdb:Manifestation in &quot;meinem&quot; Ontologie-Entwurf: Heißt das, dass diese ConceptSchemes deckungsgleich mit den Ontologie-Klassen sind und man beispielsweise die Range von zdb:hatManifestation begrenzen würde auf Objekte, die dem ConceptScheme zdbvoc:fmtype angehören?<br /> ** Ja, so wäre es zu deklarieren, wenn wir sagen wollen: die Eigenschaft Aufführungsart kann nur mit Vokabeln aus dem angegebenen Eigenschaftenvokabular ausgedrückt werden. zdbvoc:fmtype ist dann: (1) ein skos:ConceptScheme, (2) damit auch eine owl:Class und (3) ein RDF-Namensraum unter dem URI für zdbvoc:fmtype.<br /> <br /> * KR: Das mit den Named Graphs müsstest du mir glaube ich nochmal erklären. Du hast jetzt ja für jedes &quot;Untervokabular&quot; einen eigenen Namensraum erstellt. Was ist da der Vorteil?<br /> ** DB: Die Ontologie kann so Range-Restriktionen für Properties mit kontrolliertem Vokabular mittels Namensraum-URIs ausdrücken. Außerdem wird die Wartung des Gesamtvokabulars vereinfacht, wenn eine Änderung an einem isolierten Namensraum erfolgen kann.<br /> <br /> * KR: Warum zdbvoc:domain und zdbvoc:range anstelle von rdfs:range und rdfs:domain? Weil das mit der Definition von SKOS clasht?<br /> ** DB: Grundsätzlich spricht nichts gegen rdfs:range/domain. Vielleicht ist das sogar besser, weil es eine lokale Deklaration erspart.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1651 2026-07-21T14:30:49Z

<p>Dbalzer: /* Verwendungskontexte */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Plan ==<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === Verwendungskontexte ===<br /> <br /> Im ZDB-Modell wird zwischen zwei Arten von Vokabularen unterschieden: <br /> <br /> * die Tabelle &quot;reldef&quot; definiert Beziehungen der Form m:n (''many-to-many''). die in der Tabelle &quot;relation&quot; für Aussagen zu Beziehungen zwischen jeweils zwei Entitäten verwednet werden. In OWL entpricht dies dem Typ ObjectProperty.<br /> <br /> * Tabelle &quot;term&quot; definiert Beziehungen der Formen 1:n und 1:1, die als Aussagen zu verschiedenen Eigenschaften einer Entität verwendet werden. In OWL entspricht die Form 1:n dem Typ DatatypeProperty und die Form 1:1 dem Typ FunctionalProperty.<br /> <br /> Der wichtigste Unterschied ist hierbei, dass es sich bei der n:m-Relation (ObjectProperty) auf beiden Seiten (Subjekt und Objekt) um Instanzen vollwertiger Entitäten handelt, während dies bei der 1:n und der 1:1-Relation nur für das Subjekt gilt. Das Objekt ist hier lediglich ein Begriff, also ein Abtraktum, das dem Subjekt als Typus zugeordnet wird.<br /> <br /> In 1:n-Beziehungen kann es mehrere Aussagen zu einer Eigenschaft geben, beispielsweise kann eine Instanz von &quot;Person&quot; mehr als eine charakteristische Tätigkeit haben. Die 1:1-Beziehung erlaubt dagegen nur eine einmalige Eigenschaftsaussage, so darf beispielsweise eine Instanz von &quot;Aufführung&quot; nur eine einzige Aussage zum Aufführungstyp haben.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung müssen auch Anwendungs-Restriktionen berücksichtigt werden: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL) und die Eigenschaftsvokabulare für Ereignisse usw. <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> Dies würde bei Abfragen das Auswerten der Umkehrbeziehung von skos:member ersparen und insgesamt wohl auch einfacher zu pflegen sein.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher definiert und in Gebrauch sind für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, vorhandene ZDB-Datenelemente als eigene Properties zu definieren:<br /> <br /> voccredit:Animation<br /> a skos:Concept ;<br /> zdbvoc:P1 &quot;unter Namen&quot; ;<br /> zdbvoc:P2 &quot;Detail&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.<br /> <br /> == Diskussion ==<br /> <br /> * KR: Ich hatte bei der RDF-Version der ZDB-Daten immer insbesondere externe Nutzer und Nutzerinnen vor Augen. Diese benötigen Informationen/Properties wie skos:notation mit dem Rang des Credits, zdbvoc:P1 und zdbvoc:P2 mit Informationen zur Darstellung in Benutzeroberflächen ja gar nicht, oder? Vielleicht können wir hier noch etwas reduzieren. Die Reihenfolge von Credits, im Sinne der Nennung im Abspann, könnte man ja eher noch als weitere Property von zdb:Beteiligung modellieren?<br /> ** DB: Wenn wir Properties für P1/P2 und dergleichen rauslassen, brauchen wir einen anderen Ort dafür. Der Vorteil, alle für die ZDB-Bearbeitung nötigen Deklarationen mit einer RDF-Abfrage zu bekommen, wäre dann nicht mehr gegeben. Solche &quot;betriebsinternen&quot; Properties sind keineswegs unüblich und externe Nutzung beschränkt sich ohnehin auf das, was benötigt wird. Vokabular-APIs können darüber hinaus auch mit Profilen (short/standard/full oder so) versehen werden.<br /> <br /> * KR: Bei Vokabularen, in denen wir Hierarchien haben (z.B. Aufführungsart) könnte man in einem weiteren Schritt aber noch mit skos:broader und skos:narrower arbeiten, richtig? Im letzten Treffen hattest du große Einwände, aber ich glaube, das Bezog sich auf skos:ConceptSchemes?<br /> ** Die Beziehung zwischen Gruppierung und Tätigkeit folgt nicht der Definition für logische Hierarchiebeziehungen, wie von SKOS für broader/narrower gefordert (&quot;Schnitt&quot; IsA &quot;Schnitt&quot;, &quot;Licht&quot; IsA &quot;Kamera&quot; usw. sind logisch nicht haltbare Aussagen). Außerdem werden die Gruppenbezeichner nicht als Relatoren verwendet, sondern dienen nur dem Arrangement an Benutzeroberflächen. Externe Anwendungen können Credits umgruppieren, ohne dass sich die eigentliche Aussage ändert. Für Grupperungen jenseits logischer Hierarchien sieht SKOS ausdrücklich das Collection-Element vor. <br /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<br /> <br /> * KR: Noch eine Verständnisfrage zum Verhältnis der ConceptSchemes (zdbvoc:auff_art, zdbvoc:credit und zdbvoc:fmtype) zu den jeweiligen Ontologie-Klassen zdb:Veroeffentlichung, zdb:Funktion und zdb:Manifestation in &quot;meinem&quot; Ontologie-Entwurf: Heißt das, dass diese ConceptSchemes deckungsgleich mit den Ontologie-Klassen sind und man beispielsweise die Range von zdb:hatManifestation begrenzen würde auf Objekte, die dem ConceptScheme zdbvoc:fmtype angehören?<br /> ** Ja, so wäre es zu deklarieren, wenn wir sagen wollen: die Eigenschaft Aufführungsart kann nur mit Vokabeln aus dem angegebenen Eigenschaftenvokabular ausgedrückt werden. zdbvoc:fmtype ist dann: (1) ein skos:ConceptScheme, (2) damit auch eine owl:Class und (3) ein RDF-Namensraum unter dem URI für zdbvoc:fmtype.<br /> <br /> * KR: Das mit den Named Graphs müsstest du mir glaube ich nochmal erklären. Du hast jetzt ja für jedes &quot;Untervokabular&quot; einen eigenen Namensraum erstellt. Was ist da der Vorteil?<br /> ** DB: Die Ontologie kann so Range-Restriktionen für Properties mit kontrolliertem Vokabular mittels Namensraum-URIs ausdrücken. Außerdem wird die Wartung des Gesamtvokabulars vereinfacht, wenn eine Änderung an einem isolierten Namensraum erfolgen kann.<br /> <br /> * KR: Warum zdbvoc:domain und zdbvoc:range anstelle von rdfs:range und rdfs:domain? Weil das mit der Definition von SKOS clasht?<br /> ** DB: Grundsätzlich spricht nichts gegen rdfs:range/domain. Vielleicht ist das sogar besser, weil es eine lokale Deklaration erspart.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1650 2026-07-21T13:58:18Z

<p>Dbalzer: /* ZDB-Integration */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Plan ==<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === Verwendungskontexte ===<br /> <br /> Im ZDB-Modell wird zwischen zwei Arten von Vokabularen unterschieden: <br /> <br /> * die Tabelle &quot;reldef&quot; definiert Beziehungen der Form m:n (''many-to-many''). die in der Tabelle &quot;relation&quot; für Aussagen zu Beziehungen zwischen jeweils zwei Entitäten verwednet werden. In OWL entpricht dies dem Typ ObjectProperty.<br /> <br /> * Tabelle &quot;term&quot; definiert Beziehungen der Formen 1:n und 1:1, die als Aussagen zu verschiedenen Eigenschaften einer Entität verwendet werden. In OWL entspricht die Form 1:n dem Typ DatatypeProperty und die Form 1:1 dem Typ FunctionalProperty.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung müssen auch Anwendungs-Restriktionen berücksichtigt werden: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL) und die Eigenschaftsvokabulare für Ereignisse usw. <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> Dies würde bei Abfragen das Auswerten der Umkehrbeziehung von skos:member ersparen und insgesamt wohl auch einfacher zu pflegen sein.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher definiert und in Gebrauch sind für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, vorhandene ZDB-Datenelemente als eigene Properties zu definieren:<br /> <br /> voccredit:Animation<br /> a skos:Concept ;<br /> zdbvoc:P1 &quot;unter Namen&quot; ;<br /> zdbvoc:P2 &quot;Detail&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.<br /> <br /> == Diskussion ==<br /> <br /> * KR: Ich hatte bei der RDF-Version der ZDB-Daten immer insbesondere externe Nutzer und Nutzerinnen vor Augen. Diese benötigen Informationen/Properties wie skos:notation mit dem Rang des Credits, zdbvoc:P1 und zdbvoc:P2 mit Informationen zur Darstellung in Benutzeroberflächen ja gar nicht, oder? Vielleicht können wir hier noch etwas reduzieren. Die Reihenfolge von Credits, im Sinne der Nennung im Abspann, könnte man ja eher noch als weitere Property von zdb:Beteiligung modellieren?<br /> ** DB: Wenn wir Properties für P1/P2 und dergleichen rauslassen, brauchen wir einen anderen Ort dafür. Der Vorteil, alle für die ZDB-Bearbeitung nötigen Deklarationen mit einer RDF-Abfrage zu bekommen, wäre dann nicht mehr gegeben. Solche &quot;betriebsinternen&quot; Properties sind keineswegs unüblich und externe Nutzung beschränkt sich ohnehin auf das, was benötigt wird. Vokabular-APIs können darüber hinaus auch mit Profilen (short/standard/full oder so) versehen werden.<br /> <br /> * KR: Bei Vokabularen, in denen wir Hierarchien haben (z.B. Aufführungsart) könnte man in einem weiteren Schritt aber noch mit skos:broader und skos:narrower arbeiten, richtig? Im letzten Treffen hattest du große Einwände, aber ich glaube, das Bezog sich auf skos:ConceptSchemes?<br /> ** Die Beziehung zwischen Gruppierung und Tätigkeit folgt nicht der Definition für logische Hierarchiebeziehungen, wie von SKOS für broader/narrower gefordert (&quot;Schnitt&quot; IsA &quot;Schnitt&quot;, &quot;Licht&quot; IsA &quot;Kamera&quot; usw. sind logisch nicht haltbare Aussagen). Außerdem werden die Gruppenbezeichner nicht als Relatoren verwendet, sondern dienen nur dem Arrangement an Benutzeroberflächen. Externe Anwendungen können Credits umgruppieren, ohne dass sich die eigentliche Aussage ändert. Für Grupperungen jenseits logischer Hierarchien sieht SKOS ausdrücklich das Collection-Element vor. <br /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<br /> <br /> * KR: Noch eine Verständnisfrage zum Verhältnis der ConceptSchemes (zdbvoc:auff_art, zdbvoc:credit und zdbvoc:fmtype) zu den jeweiligen Ontologie-Klassen zdb:Veroeffentlichung, zdb:Funktion und zdb:Manifestation in &quot;meinem&quot; Ontologie-Entwurf: Heißt das, dass diese ConceptSchemes deckungsgleich mit den Ontologie-Klassen sind und man beispielsweise die Range von zdb:hatManifestation begrenzen würde auf Objekte, die dem ConceptScheme zdbvoc:fmtype angehören?<br /> ** Ja, so wäre es zu deklarieren, wenn wir sagen wollen: die Eigenschaft Aufführungsart kann nur mit Vokabeln aus dem angegebenen Eigenschaftenvokabular ausgedrückt werden. zdbvoc:fmtype ist dann: (1) ein skos:ConceptScheme, (2) damit auch eine owl:Class und (3) ein RDF-Namensraum unter dem URI für zdbvoc:fmtype.<br /> <br /> * KR: Das mit den Named Graphs müsstest du mir glaube ich nochmal erklären. Du hast jetzt ja für jedes &quot;Untervokabular&quot; einen eigenen Namensraum erstellt. Was ist da der Vorteil?<br /> ** DB: Die Ontologie kann so Range-Restriktionen für Properties mit kontrolliertem Vokabular mittels Namensraum-URIs ausdrücken. Außerdem wird die Wartung des Gesamtvokabulars vereinfacht, wenn eine Änderung an einem isolierten Namensraum erfolgen kann.<br /> <br /> * KR: Warum zdbvoc:domain und zdbvoc:range anstelle von rdfs:range und rdfs:domain? Weil das mit der Definition von SKOS clasht?<br /> ** DB: Grundsätzlich spricht nichts gegen rdfs:range/domain. Vielleicht ist das sogar besser, weil es eine lokale Deklaration erspart.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1649 2026-07-13T20:14:48Z

<p>Dbalzer: /* Aufgabe */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === vhost: filmstandards.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und in /fsc integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * Datenexporte, Distributionen und Konfigurationen zu unterschiedlichen Projekten -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''<br /> <br /> === vhost: collate.eu ===<br /> <br /> * Verwaiste Website auf Basis von Typo3, etliche temporäre Projektdateien -- '''archivieren'''<br /> ** verwendet Datenbank &quot;collate&quot;, eventuell auch Daten aus &quot;horde&quot;.<br /> <br /> === vhost: git.dff-film ===<br /> <br /> * Altes Git-Repository für ZDB-Programmcode, jetzt auf gitlab.api.dff.film -- '''archivieren'''<br /> ** Verwendet Datenbank &quot;gitea&quot;.<br /> <br /> === Datenbanken (MariaDB) ===<br /> <br /> * apsc - Paketverwaltung -- nicht übertragen <br /> * collate - Type3-CMS-Daten von Projekt Collate -- '''archivieren'''<br /> * difwiki - Mediawiki-Daten zum DFF-Filmografie-Wiki -- '''portieren'''<br /> * fscwiki - Mediawiki-Daten zum Basis-Wiki filmstandards.org -- '''portieren'''<br /> * gitea - erstes Git-Repository zur ZDB, abgelöst von Gitlab -- '''archivieren'''<br /> * horde - Installation der Groupware HORDE für Collate, mit einigen Benutzer-Accounts -- '''archivieren'''<br /> * information_schema - MariaDB-Interna -- nicht übertragen<br /> * mysql - MariaDB-Interna -- nicht übertragen<br /> * oai_difzf - alter Datenbestand ZDB-OAI-Dienst, fortgeführt auf oai.dff.film -- nicht übertragen <br /> * performance_schema - MariaDB-Interna -- nicht übertragen<br /> * phpmyadmin - Datenbank-Werkzeug -- nicht übertragen<br /> * psa - Systemverwaltung für den Server -- nicht übertragen</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1648 2026-07-13T20:12:53Z

<p>Dbalzer: </p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === vhost: filmstandards.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und in /fsc integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''<br /> <br /> === vhost: collate.eu ===<br /> <br /> * Verwaiste Website auf Basis von Typo3, etliche temporäre Projektdateien -- '''archivieren'''<br /> ** verwendet Datenbank &quot;collate&quot;, eventuell auch Daten aus &quot;horde&quot;.<br /> <br /> === vhost: git.dff-film ===<br /> <br /> * Altes Git-Repository für ZDB-Programmcode, jetzt auf gitlab.api.dff.film -- '''archivieren'''<br /> ** Verwendet Datenbank &quot;gitea&quot;.<br /> <br /> === Datenbanken (MariaDB) ===<br /> <br /> * apsc - Paketverwaltung -- nicht übertragen <br /> * collate - Type3-CMS-Daten von Projekt Collate -- '''archivieren'''<br /> * difwiki - Mediawiki-Daten zum DFF-Filmografie-Wiki -- '''portieren'''<br /> * fscwiki - Mediawiki-Daten zum Basis-Wiki filmstandards.org -- '''portieren'''<br /> * gitea - erstes Git-Repository zur ZDB, abgelöst von Gitlab -- '''archivieren'''<br /> * horde - Installation der Groupware HORDE für Collate, mit einigen Benutzer-Accounts -- '''archivieren'''<br /> * information_schema - MariaDB-Interna -- nicht übertragen<br /> * mysql - MariaDB-Interna -- nicht übertragen<br /> * oai_difzf - alter Datenbestand ZDB-OAI-Dienst, fortgeführt auf oai.dff.film -- nicht übertragen <br /> * performance_schema - MariaDB-Interna -- nicht übertragen<br /> * phpmyadmin - Datenbank-Werkzeug -- nicht übertragen<br /> * psa - Systemverwaltung für den Server -- nicht übertragen</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1647 2026-07-13T20:09:51Z

<p>Dbalzer: /* vhost: filmstandards.org */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === vhost: filmstandards.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und in /fsc integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''<br /> <br /> === vhost: collate.eu ===<br /> <br /> * Verwaiste Website auf Basis von Typo3, etliche temporäre Projektdateien -- '''archivieren'''<br /> ** verwendet Datenbank &quot;collate&quot;, eventuell auch Daten aus &quot;horde&quot;.<br /> <br /> === vhost: git.dff-film ===<br /> <br /> * Altes Git-Repository für ZDB-Programmcode, jetzt auf gitlab.api.dff.film -- '''archivieren'''<br /> ** Verwendet Datenbank &quot;gitea&quot;.<br /> <br /> === Datenbanken (MariaDB) ===<br /> <br /> * apsc - Paketverwaltung -- nicht übertragen <br /> * collate - Type3-CMS-Daten von Projekt Collate -- '''archivieren'''<br /> * difwiki - Mediawiki-Daten zum DFF-Filmografie-Wiki -- '''portieren'''<br /> * fscwiki - Mediawiki-Daten zum Basis-Wiki filmstandards.org -- '''portieren'''<br /> * gitea - erstes Git-Repository zur ZDB, abgelöst von Gitlab -- '''archivieren'''<br /> * horde - Installation der Groupware HORDE für Collate, mit einigen Benutzer-Accounts -- '''archivieren'''<br /> * information_schema - MariaDB-Interna -- nicht übertragen<br /> * mysql - MariaDB-Interna -- nicht übertragen<br /> * oai_difzf - alter Datenbestand ZDB-OAI-Dienst, fortgeführt auf oai.dff.film -- nicht übertragen <br /> * performance_schema - MariaDB-Interna -- nicht übertragen<br /> * phpmyadmin - Datenbank-Werkzeug -- nicht übertragen<br /> * psa - Systemverwaltung für den Server -- nicht übertragen</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1646 2026-07-13T20:08:08Z

<p>Dbalzer: /* vhost: collate.eu */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === vhost: filmstandards.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''<br /> <br /> === vhost: collate.eu ===<br /> <br /> * Verwaiste Website auf Basis von Typo3, etliche temporäre Projektdateien -- '''archivieren'''<br /> ** verwendet Datenbank &quot;collate&quot;, eventuell auch Daten aus &quot;horde&quot;.<br /> <br /> === vhost: git.dff-film ===<br /> <br /> * Altes Git-Repository für ZDB-Programmcode, jetzt auf gitlab.api.dff.film -- '''archivieren'''<br /> ** Verwendet Datenbank &quot;gitea&quot;.<br /> <br /> === Datenbanken (MariaDB) ===<br /> <br /> * apsc - Paketverwaltung -- nicht übertragen <br /> * collate - Type3-CMS-Daten von Projekt Collate -- '''archivieren'''<br /> * difwiki - Mediawiki-Daten zum DFF-Filmografie-Wiki -- '''portieren'''<br /> * fscwiki - Mediawiki-Daten zum Basis-Wiki filmstandards.org -- '''portieren'''<br /> * gitea - erstes Git-Repository zur ZDB, abgelöst von Gitlab -- '''archivieren'''<br /> * horde - Installation der Groupware HORDE für Collate, mit einigen Benutzer-Accounts -- '''archivieren'''<br /> * information_schema - MariaDB-Interna -- nicht übertragen<br /> * mysql - MariaDB-Interna -- nicht übertragen<br /> * oai_difzf - alter Datenbestand ZDB-OAI-Dienst, fortgeführt auf oai.dff.film -- nicht übertragen <br /> * performance_schema - MariaDB-Interna -- nicht übertragen<br /> * phpmyadmin - Datenbank-Werkzeug -- nicht übertragen<br /> * psa - Systemverwaltung für den Server -- nicht übertragen</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1645 2026-07-13T20:07:09Z

<p>Dbalzer: /* vhost: collate.eu */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === vhost: filmstandards.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''<br /> <br /> === vhost: collate.eu ===<br /> <br /> * Verwaiste Website auf Basis von Typo3, etliche temporäre Projektdateien -- '''archivieren'''<br /> ** verwendet Datenbank &quot;collate&quot;, eventuell auch Daten aus &quot;horde&quot;.<br /> <br /> === vhost: git.dff-film<br /> <br /> * Erstes Git-Repository für ZDB-Programmcode, weitergeführt auf gitlab.api.dff.film -- '''archivieren'''<br /> ** Verwendet Datenbank &quot;gitea&quot;.<br /> <br /> === Datenbanken (MariaDB) ===<br /> <br /> * apsc - Paketverwaltung -- nicht übertragen <br /> * collate - Type3-CMS-Daten von Projekt Collate -- '''archivieren'''<br /> * difwiki - Mediawiki-Daten zum DFF-Filmografie-Wiki -- '''portieren'''<br /> * fscwiki - Mediawiki-Daten zum Basis-Wiki filmstandards.org -- '''portieren'''<br /> * gitea - erstes Git-Repository zur ZDB, abgelöst von Gitlab -- '''archivieren'''<br /> * horde - Installation der Groupware HORDE für Collate, mit einigen Benutzer-Accounts -- '''archivieren'''<br /> * information_schema - MariaDB-Interna -- nicht übertragen<br /> * mysql - MariaDB-Interna -- nicht übertragen<br /> * oai_difzf - alter Datenbestand ZDB-OAI-Dienst, fortgeführt auf oai.dff.film -- nicht übertragen <br /> * performance_schema - MariaDB-Interna -- nicht übertragen<br /> * phpmyadmin - Datenbank-Werkzeug -- nicht übertragen<br /> * psa - Systemverwaltung für den Server -- nicht übertragen</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1644 2026-07-13T20:01:20Z

<p>Dbalzer: /* Datenbanken (MariaDB) */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === vhost: filmstandards.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''<br /> <br /> === vhost: collate.eu ===<br /> <br /> * Verwaiste Website auf Basis von Typo3, etliche temporäre Projektdateien -- '''archivieren'''<br /> <br /> <br /> === Datenbanken (MariaDB) ===<br /> <br /> * apsc - Paketverwaltung -- nicht übertragen <br /> * collate - Type3-CMS-Daten von Projekt Collate -- '''archivieren'''<br /> * difwiki - Mediawiki-Daten zum DFF-Filmografie-Wiki -- '''portieren'''<br /> * fscwiki - Mediawiki-Daten zum Basis-Wiki filmstandards.org -- '''portieren'''<br /> * gitea - erstes Git-Repository zur ZDB, abgelöst von Gitlab -- '''archivieren'''<br /> * horde - Installation der Groupware HORDE für Collate, mit einigen Benutzer-Accounts -- '''archivieren'''<br /> * information_schema - MariaDB-Interna -- nicht übertragen<br /> * mysql - MariaDB-Interna -- nicht übertragen<br /> * oai_difzf - alter Datenbestand ZDB-OAI-Dienst, fortgeführt auf oai.dff.film -- nicht übertragen <br /> * performance_schema - MariaDB-Interna -- nicht übertragen<br /> * phpmyadmin - Datenbank-Werkzeug -- nicht übertragen<br /> * psa - Systemverwaltung für den Server -- nicht übertragen</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1643 2026-07-13T19:58:27Z

<p>Dbalzer: /* Datenbanken */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === vhost: filmstandards.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''<br /> <br /> === vhost: collate.eu ===<br /> <br /> * Verwaiste Website auf Basis von Typo3, etliche temporäre Projektdateien -- '''archivieren'''<br /> <br /> <br /> === Datenbanken (MariaDB) ===<br /> <br /> * apsc - Paketverwaltung -- nicht übertragen <br /> * collate - Type3-CMS-Daten von Projekt Collate -- '''archivieren'''<br /> * difwiki - Mediawiki-Daten zum DFF-Filmografie-Wiki -- '''portieren'''<br /> * fscwiki - Mediawiki-Daten zum Basis-Wiki filmstandards.org -- '''portieren'''<br /> * gitea - erstes Git-Repository zur ZDB, abgelöst von Gitlab -- '''archivieren'''<br /> * horde - Installation der Groupware HORDE mit einigen Benutzer-Accounts -- '''archivieren'''<br /> * information_schema - MariaDB-Interna -- nicht übertragen<br /> * mysql - MariaDB-Interna -- nicht übertragen<br /> * oai_difzf - erster Datenbestand OAI-Dienst für ZDB, jetzt auf oai.dff.film -- nicht übertragen |<br /> * performance_schema - MariaDB-Interna -- nicht übertragen<br /> * phpmyadmin - Datenbank-Werkzeug -- nicht übertragen<br /> * psa - Systemverwaltung für den Server -- nicht übertragen</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1642 2026-07-13T19:47:01Z

<p>Dbalzer: /* filmstandrds.org */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === vhost: filmstandards.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''<br /> <br /> === vhost: collate.eu ===<br /> <br /> * Verwaiste Website auf Basis von Typo3, etliche temporäre Projektdateien -- '''archivieren'''<br /> <br /> <br /> === Datenbanken ===<br /> <br /> apsc - Paketverwaltung -- nicht übertragen <br /> collate - Type3-CMS-Daten von Projekt Collate -- '''archivieren'''<br /> difwiki - Mediawiki-Daten zum DFF-Filmografie-Wiki -- '''portieren'''<br /> fscwiki - Mediawiki-Daten zum Basis-Wiki filmstandards.org -- '''portieren'''<br /> gitea - erstes Git-Repository zur ZDB, abgelöst von Gitlab -- '''archivieren'''<br /> horde <br /> information_schema - MariaDB-Interna -- nicht übertragen<br /> mysql - MariaDB-Interna -- nicht übertragen<br /> oai_difzf |<br /> performance_schema - MariaDB-Interna -- nicht übertragen<br /> phpmyadmin - Datenbank-Werkzeug -- nicht übertragen<br /> psa - Systemverwaltung für den Server -- nicht übertragen</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1641 2026-07-13T07:41:11Z

<p>Dbalzer: /* filmstandrds.org */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === filmstandrds.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1640 2026-07-13T07:40:21Z

<p>Dbalzer: /* filmstandrds.org */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === filmstandrds.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1639 2026-07-13T07:39:16Z

<p>Dbalzer: /* filmstandrds.org */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === filmstandrds.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und besser integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1638 2026-07-13T07:38:24Z

<p>Dbalzer: /* filmstandrds.org */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === filmstandrds.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und besser integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> * diverse Dienstprogramme, u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer<br /> -- '''portieren'''<br /> <br /> '''uploads/'''<br /> * verschiedene Datenexporte, Distributionen und Konfiguearionen -- '''archivieren'''<br /> <br /> '''vocab/'''<br /> * temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1637 2026-07-13T07:29:53Z

<p>Dbalzer: /* filmstandrds.org */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === filmstandrds.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und besser integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> * Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''<br /> <br /> '''schemas/'''<br /> * XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''<br /> <br /> '''svc/'''<br /> <br /> '''uploads/'''<br /> <br /> '''vocab/'''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1636 2026-07-12T15:57:10Z

<p>Dbalzer: /* Aufgabe */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === filmstandrds.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und besser integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> <br /> '''schemas/'''<br /> <br /> '''svc/'''<br /> <br /> '''uploads/'''<br /> <br /> '''vocab/'''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1635 2026-07-12T15:54:54Z

<p>Dbalzer: /* filmstandrds.org */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch einige zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === filmstandrds.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und besser integrieren<br /> <br /> '''midas/'''<br /> * Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?'''<br /> <br /> '''mmi/'''<br /> * Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?'''<br /> <br /> '''news/'''<br /> <br /> '''schemas/'''<br /> <br /> '''svc/'''<br /> <br /> '''uploads/'''<br /> <br /> '''vocab/'''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1634 2026-07-12T15:48:29Z

<p>Dbalzer: /* filmstandrds.org */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch einige zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === filmstandrds.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> <br /> '''img/'''<br /> * Schriften und Logo zu /fsc -- '''portieren''' und besser integrieren<br /> <br /> '''installed/'''<br /> * Distribution von mediawiki-1.16.2 -- kann weg<br /> <br /> '''localdefs/'''<br /> * Erster Entwurf eines RDF-Schemas für die ZDB -- '''archivieren'''<br /> <br /> '''media/'''<br /> * Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und besser integrieren<br /> <br /> '''midas/'''<br /> <br /> '''mmi/'''<br /> <br /> '''news/'''<br /> <br /> '''schemas/'''<br /> <br /> '''svc/'''<br /> <br /> '''uploads/'''<br /> <br /> '''vocab/'''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Migration_filmstandards.org&diff=1633 2026-07-12T15:39:29Z

<p>Dbalzer: /* filmstandrds.org */</p> <hr /> <div>== Aufgabe ==<br /> <br /> Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch einige zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.<br /> <br /> === filmstandrds.org ===<br /> <br /> '''cen/'''<br /> * Veraltetes zum CEN-Standard (2010) -- kann weg<br /> <br /> '''demo/'''<br /> * Visulisierungs-Experiment von 2011 -- kann weg<br /> <br /> '''difzf/'''<br /> * Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''<br /> ** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.<br /> <br /> '''dokuwiki/'''<br /> * Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg<br /> <br /> '''efg/'''<br /> * Link-Seite von 2009 zum EFG -- kann weg.<br /> <br /> '''fiaf/'''<br /> * Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg<br /> <br /> '''fsc/'''<br /> * Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''<br /> <br /> '''img/'''<br /> <br /> '''installed/'''<br /> <br /> '''localdefs/'''<br /> <br /> '''media/'''<br /> <br /> '''midas/'''<br /> <br /> '''mmi/'''<br /> <br /> '''news/'''<br /> <br /> '''schemas/'''<br /> <br /> '''svc/'''<br /> <br /> '''uploads/'''<br /> <br /> '''vocab/'''</div>

Dbalzer