Metainformationen zur Seite
  •  

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
bc_json [2025/11/30 13:44] – bcadminbc_json [2025/12/11 10:13] (aktuell) – bcadmin
Zeile 16: Zeile 16:
 <WRAP twothirds column> <WRAP twothirds column>
  
 +===== Einleitung =====
 +
 +Die BeeCollect Cloud erlaubt es ihren Teilnehmern nicht nur, Daten für externe Akteure bereitzustellen, sondern dient auch dem Datenaustausch zwischen verschiedenen BeeCollect-Datenbanken. Um dabei eine zuverlässige Zwei-Wege-Synchronisation zu gewährleisten, werden neben der entsprechenden Applikationslogik zwei essentielle Dinge benötigt:
 +
 +  - Alle zu synchronisierenden Datensätze benötigen **global eindeutige Datensatzschlüssel**, und zwar auf allen Ebenen.
 +  - Das für den Datentransfer verwendete **Format muss diese Schlüssel transportieren** können - ebenfalls auf allen Ebenen.
 +
 +Die erste Bedingung wird von BeeCollect Professional erfüllt: Jeder Datensatz, auch auf nachgeordneten Ebenen wie Maßangaben, Provenienzen oder Verknüpfungen, besitzt vom Beginn seiner Existenz an einen global eindeutigen Schlüssel im standardisierten GUID/UUID-Format.
 +
 +Die zweite Bedingung erfüllen die allermeisten der standardisierten Datenformate wie LIDO oder EDM nicht. Auch sind diese von der Handhabung aufgrund ihres internen Aufbaus eher aufwändig. Daher verwendet die BeeCollect Cloud für den Transfer zwischen BeeCollect-Datenbanken ein eigenes Datenformat auf Basis von JSON. Das Format ist von der Grundstruktur einfach aufgebaut, lässt sich gut aus einem oder in ein Objektmodell serialisieren/deserialisieren und ist in der Lage, die vollständige aktuelle Datenstruktur von BeeCollect Professional aufzunehmen. Darüber hinaus bietet es genügend Flexibilität, um auch künftige Erweiterungen und Anforderungen abdecken zu können.
 +
 +===== Grundsätzlicher Aufbau von JSON ====
 +
 +Das JSON-Datenformat unterstützt generell drei Arten von Elementen:
 +
 +  * Schlüssel-Wert-Paar
 +  * Komplexe Objekte 
 +  * Auflistungen (aus strukturell identischen Elementen)
 +
 +Diese Elemente können beliebig in einander verschachtelt werden: Eine Auflistung besteht immer aus Elementen mit gleicher Struktur. Das kann ein Schlüssel-Wert-Paar, aber auch ein komplexes Objekt sein. Und ein Schlüssel-Wert-Paar kann als "Wert" wiederum ein komplexes Objekt verwenden. Und komplexe Objekte können sowohl aus Schlüssel-Wert-Paaren, Auflistungen oder weiteren komplexen Objekten bestehen.
 +
 +Damit ist JSON sehr gut geeignet, auch stark verschachtelte Datenstrukturen detailgetreu abzubilden.
 +
 +In dieser Dokumentation wird das dem BC_JSON zugrundeliegende Objektmodell beschrieben, unterstützt von Beispielen, wie dieses Objektmodell sich dann als JSON darstellt.
 +
 +===== Aufbau der BC_JSON-Datenstruktur ===== 
 +
 +Eine Entität (also z.B. ein Sammlungsobjekt, eine Person oder Organisation oder eine Publikation) wird im **BC_JSON** über ein sogenanntes //DataExchangeItem// abgebildet. Dieses enthält dann wiederum verschiedene Elemente, welche die Metadaten dieser Entität repräsentieren.
 +
 +Die gesamte Objekthierarchie des BC_JSON setzt sich aus folgenden Objekten zusammen:
 +
 +  * [[bc_json:dataexchangeitem|DataExchangeItem]]
 +  * [[bc_json:datalist|dataList]]
 +  * [[bc_json:datalistitem|dataListItem]]
 +  * [[bc_json:datafield-text|dataField_Text]]
 +  * [[bc_json:datafield-integer|dataField_Integer]]
 +  * [[bc_json:datafield-float|dataField_Float]]
 +  * [[bc_json:datafield-datetime|dataField_DateTime]]
 +  * [[bc_json:datafield-boolean|dataField_Boolean]]
 +  * [[bc_json:datafield-typedstring|dataField_TypedString]]
 +  * [[bc_json:datafield-dimension|dataField_Dimension]]
 +  * [[bc_json:datafield-dating|dataField_Dating]]
 +  * [[bc_json:datafield-medium|dataField_Medium]]
 +  * [[bc_json:datafield-reference|dataField_Reference]]
  
 </WRAP> </WRAP>
 </WRAP> </WRAP>
  
↑