System: created und modified fehlt im Beispiel

[robbi5]

created und modified sind laut 3.3.5 / 3.3.6 zwingend. In der Tabelle ist es noch enthalten, im Beispiel fehlt es.

[akuckartz]

Eventuell ist die Spezifikation in den genannten Abschnitten veränderungswürdig: Wenn diese Information z.B. bei alten Daten nicht vorhanden ist, dann kann sie nicht korrekt ausgegeben werden.

[konstin]

Wenn diese Information z.B. bei alten Daten nicht vorhanden ist, dann kann sie nicht korrekt ausgegeben werden.

In diesem Fall wird bei der Einrichtung von OParl einfach created und modified auf den aktuellen Zeitpunkt gesetzt, da erst ab diesem Zetipunkt die OParl-Objekte existieren und das Erstellen auch eine Veränderung ist.

[akuckartz]

@konstin

• Das steht nicht in der Spezifikation und ergibt sich auch nicht implizit.
• Dann kann jemand der die Daten nutzen möchte nicht wissen worauf sich die Zeitstempel beziehen. Damit sind Fehler vorprogrammiert.

[konstin]

Das steht nicht in der Spezifikation und ergibt sich auch nicht implizit.

Doch, in der Spezifikation steht nämlich, dass sich created auf "Datum und Uhrzeit der Erstellung des jeweiligen Objekts" (Kapitel 3.3.5) bezieht. Vor der Einrichtung einer OParl-Schnittstelle existieren keine OParl-Objekte für die alten Daten, danach schon. Der Zeitpunkt der Erstellung ist also die Einrichtung der Schnittstelle. Da die Erstellung wie bereits erwähnt eine Veränderung von nicht vorhanden zu einem Oparl-Objekt ist, muss modified am Anfang auf den gleichen Zeitpunkt wie created gesetzt werden.

Dann kann jemand der die Daten nutzen möchte nicht wissen worauf sich die Zeitstempel beziehen.

Doch, kann man, denn die Zeitstempel beziehen auf den Zeitpunkt der Erstellung bzw. den Zeitpunkt der letzten Änderung des OParl-Objekts. Für Informationen über die Erstellung dessen, was das OParl-Objekt darstellt, gibt es übrigens eigene Attribute, wie z.B. date in oparl:File.

Damit sind Fehler vorprogrammiert.

Mir ist kein Fall bekannt, bei dem ein spezifikationsgemäßer Gebrauch der beiden Attribute zu einem Fehler führen könnte.

[akuckartz]

@konstin Es kann sein, dass ich etwas übersehen habe, aber ich meine, dass der Begriff "Objekt" in dem Dokument nicht definiert ist. Jedenfalls scheint es mir nicht unbedingt offensichtlich zu sein, dass damit nicht die zugrundeliegenden Daten gemeint sind. Wenn man unter "Erstellung des jeweiligen Objekts" die Generierung eines JSON-Dokuments versteht, dann kann es immer neu erstellt werden - mit den entsprechenden Auswirkungen auf beide Zeitstempel. Soll das konform zur Spezifikation sein oder nicht?

Worin besteht unter diesen Umständen der Nutzen von zwei Attributen mit Zeitstempeln statt nur einem? Reicht modified (oder timestamp) nicht aus?

Wenn ich nach Daten aus dem Jahr 2015 suche und die Objekte wurden erst 2016 erzeugt, dann finde ich nichts. Das erscheint mir problematisch zu sein.

[konstin]

Es kann sein, dass ich etwas übersehen habe, aber ich meine, dass der Begriff "Objekt" in dem Dokument nicht definiert ist. Jedenfalls scheint es mir nicht unbedingt offensichtlich zu sein, dass damit nicht die zugrundeliegenden Daten gemeint sind. Wenn man unter "Erstellung des jeweiligen Objekts" die Generierung eines JSON-Dokuments versteht, dann kann es immer neu erstellt werden - mit den entsprechenden Auswirkungen auf beide Zeitstempel. Soll das konform zur Spezifikation sein oder nicht?

Dieses Problem wird durch die eindeutige id gelöst. Ein Objekt entspricht dabei genau einer id. Es existiert also, sobald unter der URL, die seine id ist, ein Objekt verfügbar ist. Wenn also einer URL zweimal abgefragt wird, wird damit dasselbe Objekt abgefragt, das somit auch zum gleichen Zeitpunkt erstellt wurde.

Worin besteht unter diesen Umständen der Nutzen von zwei Attributen mit Zeitstempeln statt nur einem? Reicht modified (oder timestamp) nicht aus?

Die beiden Attribute sind nur im Zusammenhang mit externen Listen wirklich nützlich. Ein Client kann z.B. alle seit der letzten Synchronisation neu hinzugekommenen Objekte abfragen, indem created als Listenfilter benutzt. Wenn ein Client alle Änderungen seit der letzten Synchronisation haben möchte, kann er einfach mit modified filtern. Dasselbe gilt für Clients, die zwar nicht alles synchronisieren, aber einen lokalen Cache anlegen.

Wenn ich nach Daten aus dem Jahr 2015 suche und die Objekte wurden erst 2016 erzeugt, dann finde ich nichts. Das erscheint mir problematisch zu sein.

Das ist tatsächlich ein Problem, aber leider eines, das OParl nicht lösen kann. Denn leider gibt es Systeme, in denen einfach keine verlässlichen Zeitstempel für deren alte Daten gibt. Für den im Beispiel genannten Fall gibt es oparlSince in oparl:Body, damit ein Client und/oder Nutzer diesen Umstand erkennen und entsprechen behandeln kann.

created und modified werden übrigens wie in den Tabellen angegeben nur für nicht-intern ausgegebene Objekte verwendet, was ich in c772c3d für Kapitel 3.3 korrigiert habe.

[akuckartz]

OK, danke. Das vereinfacht für mich auch die Beurteilung ob bzw. inwieweit diese Eigenschaften Bestandteil des Vokabulars / Informationsmodells sind oder eher außerhalb zu sehen sind.