EN15907-XML-Allgemeine Überlegungen

Allgemeine Fragen

Müssen wir das Root-Element ExchangeSet in irgendeiner Form in eine der Schemadefinitionen übernehmen? --Mfreiberg (Diskussion) 16:41, 17. Nov. 2017 (CET)

Ich votiere dafür. Das verhindert, dass jemand auf die Idee kommt, sich sich ein eigenes Rahmenelement zu backen. DBalzer

---

Wofür sind die Attribute sourceID und numeric vorgesehen? --Mfreiberg (Diskussion) 16:41, 17. Nov. 2017 (CET)

sourceId bietet die Möglichkeit, Knoten in geschachtelten Datenstrukturen eine Identität zu geben. Bei Exporten aus der DIF-Datenbank wären das die UIDs z.B. von Manifestationen, Titeln, Ereignissen, usw.

Solche Knoten-Identitäten sind nützlich, wenn ähnlich strukturierte Daten aus verschiedenen Quellen zusammengefügt werden sollen. Besonders nützlich sind sie im Hinblick auf eine RDF-Darstellung, wo man sogenannte "blank nodes" zu vermeiden oder zu eliminieren versucht (dort bekannt als Skolemisierung[1]).

Die unterschiedlichen Schreibweisen sourceID und sourceId im ersten Schema-Release sollten vereinheitlicht, besser noch in nodeId geändert werden.

Das Attribut numeric ist eine Altlast, die (soweit ich mich erinnere) mal aus dem bibliothekarischen Umfeld in dieses Schema hineingeraten ist. Mir fällt derzeit keine sinnvolle Anwendung dafür ein. --DBalzer (Diskussion) 21:08, 28. Nov. 2017 (CET)

---

Das Schema schreibt den Datentyp xs:anyURI für das Attribut scheme vor. In vielen Fällen wird aber kein URI angegeben werden, z.B. UUID im Element Identifier oder ISIL (ISO 15511) im Element SourceIdentifier. Gleiches gilt für das Attribut vocSource in HasAgent/Activity, das mit local als Defaultwert daherkommt. --Mfreiberg (Diskussion) 16:41, 17. Nov. 2017 (CET)

Betr. Identifier: ISIL haben einen LOD-Namensraum: [2] ; UUIDs haben einen URN-Namensraum (z.B. urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6).

Die DIF-eigenen Vokabulare sind derzeit tatsächlich noch sowas wie "local", aber die sollten eigentlich so bald wie möglich als LOD-Ressource öffentlich referenzierbar gemacht werden. Vor über 5 Jahren hatte ich mal damit angefangen, davon was in einen RDF-Triplestore zu legen (siehe [3]), aber das ging seinerzeit noch mangels Interesse unter.

Bis wir durchgängig LOD-URIs haben, werden wir die DIF-eigenen Vokabulare noch als Wertelisten parat halten müssen. Da haben sie wenigstens schon den Namensraum des Anwendungsschemas und eine Typzugehörigkeit. --DBalzer (Diskussion) 21:25, 28. Nov. 2017 (CET)

---

Zur Differenzierung von vocabularySource und vocSource (oder auch von URI- und String-Identifier) schlage ich vor, dass das Schema einen abstrakten Typ VocabularyType definiert und davon zwei Ableitungen: URIVocabularyType und LocalVocabularyType. Ersterer schreibt für den Elementinhalt und das Attribut VocabularySource als Datentyp xs:anyURI vor, letzterer begnügt sich in beiden Fällen mit xs:anyString. In der XML-Instanz werden die vokabularfähigen Elemente dann typisiert. Du kannst am besten beurteilen, ob der Vorschlag eine praktikable Lösung ist. --Mfreiberg (Diskussion) 16:41, 17. Nov. 2017 (CET)

Ja, das sollte irgendwie klarer herausgearbeitet werden. Ich versuche mich mal daran.

Mit einer echten LOD-Implementierung würden solche Probleme von selbst verschwinden, denn da wird jedes Vokabularelement, egal ob weltbekannt oder gerade eben ausgedacht, als URI referenziert.--DBalzer (Diskussion) 09:07, 29. Nov. 2017 (CET)

---

Wie würde Erweiterungen von festen Wertelisten in der ZDB in das Anwendungsschema übernommen werden? Denkbar z.B. beim Typ AgentActivityType. --Mfreiberg (Diskussion) 16:41, 17. Nov. 2017 (CET)

Mir fällt dazu nur eine Versionierung der Anwendungsschemata ein. Solange einzelne Werte in der Datenbank nicht retrospektiv geändert werden (schönere oder treffendere Bezeichnung oder so), wäre das inkrementell zu machen. Neuere Versionen des Anwendungsschemas würden einfach nur zusätzliche Vokabeln als zulässig definieren, alle bisherigen bleiben gültig.

Retrospektive Änderungen sollten unnötig sein, weil in den Tabellen term und reldef zwischen interner (und damit persistenter) Darstellung und (änderbarer) externer Darstellung für Benutzeroberflächen unterschieden wird. --DBalzer (Diskussion) 20:28, 28. Nov. 2017 (CET)

---

Wie gehen wir mit den Länderkürzeln um, die nicht Teil von ISO 3166-1 sind? DD, D1, D2 etc. Das Attribut scheme müsste in diesen Fällen anders belegt sein, aber wie? --Mfreiberg (Diskussion) 16:41, 17. Nov. 2017 (CET)

Naiverweise wäre das ein Fall für scheme="local". In einem bidirektionalen Datenaustausch gibt es aber mehrere Lokalitäten, so dass wir wohl oder übel hier den Urheber des Ländercodes angeben müssen, also z.B. scheme="DIF".

Mit einer echten LOD-Implementierung wären wir hier besser dran. Dann würde der URI-Namensraum das scheme-Attribut überflüssig machen. Obendrein würde die publizierte RDF-Ressource auch noch angeben können, dass z.B. DIF "DD" äquivalent zu BArch "DDDE" und beides wiederum gleichbedeutend mit [4] ist.--DBalzer (Diskussion) 08:54, 29. Nov. 2017 (CET)