Leere Objekte untersagen

[black-snow]

Leere Objekte sollten pauschal nicht zulässig sein. Es sollte nicht möglich sein einen Pflichtwert schlicht mit einem leeren Objekt zu füllen. Dabei bedeutet "leer" wohl gerade, dass keine tatsächlichen Werte vorliegen. Ein Objekt mit Kontext aber ohne Werte ist ebenfalls als leer zu betrachten.

[marians]

Hierzu noch als Hintergrund: Wir haben uns die Frage gestellt, ob beim oparl:Location Objekt eine der beiden Eigenschaften (description oder geometry) ZWINGEND vorhanden sein sollte. Allerdings wäre das praxisfern, weil es Fälle geben kann, in denen nur description vorhanden ist, und andere, in denen nur geometry geliefert werden kann.

Um den unsinnigen Fall abzudecken, dass ein Objekt völlig ohne Eigenschaften ausgeliefert wird, schlagen wir diese zusätzliche Anforderung vor.

[akuckartz]

Einverstanden. Zur Präzisierung und Erweiterung:

• Eigenschaften mit dem nach JSON-LD Spezifikation zulässigen Wert null wären als leer und damit unzulässig anzusehen. Dass sollte vorsorglich klargestellt werden.
• JSON-LD Objekte die aus RDF-Sicht keine Tripel enthalten sind als leer anzusehen und deshalb unzulässig. Das bedeutet nach meiner Einschätzung aktuell nur, dass die Spezifikation der Listen noch nach JSON-LD umgestellt werden muss, aber das ist eine bekannte Baustelle.

[Telofy]

In verschiedenen Projekten hab ich es als nützlich empfunden verschiedene Mengen von Objekten aus unseren JSON-Objekten rekursiv rauszufiltern, um sie in eine kanonische Form zu bringen, wozu ich diese Funktion benutze. In der Regel ist das nur None, a.k.a. null, aber teilweise auch (None, '', {}, []). Das ist alles für Python-Dictionaries gedacht, die letztlich in JSON-Objekten enkodiert werden sollen, so dass ich Unterklassen und Tupel nicht beachte.

>>> canonicalized({'pony': 'Twilight Sparkle', 'middle_name': '', 'flaws': {'character_flaws': None}}, blacklist=(None, {}, ''))
{'pony': 'Twilight Sparkle'}

Vielleicht ließe sich dementsprechend die neue Anforderung einfach als eine Definition einer solchen kanonischen Form beschreiben. Besonders die rekursive Natur der Filterung könnte noch wichtig sein.

[akuckartz]

Ist "[]" als Wert JSON-LD konform? Habe ich nicht geprüft, falls ja, dann sollte das auch als leer und für OParl unzulässig erklärt werden. Eine solche Eigenschaft würde 0 RDF-Tripeln entsprechen.

[marians]

Vorsicht, dass wir hier nicht über's Ziel hinaus schießen. Folgender Fall ist in der Praxis denkbar:

Der RIS-Betreiber legt ein neues Gremium (oparl:Organization) an. Noch bevor er die ersten Mitglieder zum Gremium hinzufügen kann, ist es 17 Uhr, und der Sachbearbeiter muss die Arbeit leider unterbrechen.

Das System sollte diese Gruppierung ohne Mitglieder trotzdem ausgeben dürfen. Nun ist member aber eine zwingende Eigenschaft. Der einzig sonnvolle Wert dafür wäre meiner Ansicht nach "member": [].

[marians]

Zu leeren Arrays finde ich in JSON-LD keine Aussage. Daher sollte es erlaubt sein.

[akuckartz]

Es ist widersprüchlich, wenn für eine "zwingende" Eigenschaft vorgesehen wird, dass sie dennoch "leer" sein darf. Der Informationsgehalt einer solchen "leeren" Eigenschaft ist identisch zur Situation, dass sie nicht vorhanden ist: es gibt kein Tripel für die Beziehung - im konkreten Fall: es gibt kein Mitglied. (Ein Gremium kann übrigens durchaus auch unter anderen Umständen längere Zeit ohne Mitglieder bleiben.)

"ZWINGEND" sollte strikt wie ein Constraint einer relationalen Datenbank behandelt werden, also jederzeit gelten.

Die Auflösung des Widerspruchs besteht in der Lockerung der Eigenschaft zu "EMPFOHLEN".

[marians]

@akuckartz Ich gebe Dir Recht. Macht Sinn.

[marians]

Habe die Formulierung in commit 5fc81759e054172b5f882d38dae62a3e53825639 für leere Objekte ergänzt.