PROV Ontology berücksichtigen

[akuckartz]

Die Eigenschaften dieser Ontologie sollten - wo relevant - verwendet werden:

PROV-O: The PROV Ontology
W3C Recommendation 30 April 2013
http://www.w3.org/TR/prov-o/

Beispiele sind generatedAtTime, wasDerivedFrom und wasGeneratedBy.

[akuckartz]

Diese Eigenschaften sollten umbenannt (bzw. entfernt) oder auf die prov-Eigenschaften abgeblidet werden:

• originator in oparl:Paper entspricht wasAttributedTo (nicht prov:wasGeneratedBy)
• masterDocument in oparl:Document entspricht prov:wasDerivedFrom
• derivativeDocument in oparl:Document ist die inverse Eigenschaft zu masterDocument bzw. prov:wasDerivedFrom. Aber die prov-Ontologie rät explizit dazu diese inverse Eigenschaft nicht zu verwenden (http://www.w3.org/TR/prov-o/#inverse-names).

[marians]

Wenn ich den dritten Teil des vorigen Kommentars richtig verstehe, geht es um die Frage, ob wir eine der beiden "Verlinkungen" einsparen können. Ich glaube nicht. Sowohl derivativeDocument als auch masterDocument haben aus meiner Sicht ihre Berechtigung.

Beispiel 1: Eine Drucksache (oparl:Paper) verweist auf ein Dokument, dieses wurde in MS Word erstellt und ist im Format DOCX. Der Client kann mit DOCX nichts anfangen. Glücklicherweise verweist das Dokument mittels derivativeDocument auf eine PDF-Version. Diese kann der Client verarbeiten.

Beispiel 2: Eine Sitzung (oparl:Meeting) verweist auf ein Dokument, es handelt sich um ein PDF. Über die Eigenschaft masterDocument verweist es auf ein anderes Dokument. Der Client ruft auch dieses Dokument ab, um zu prüfen, ob es sich dabei um ein Format handelt, dass der Client noch einfacher verarbeiten kann und ihm mehr Möglichkeiten bietet, als das PDF.

[akuckartz]

Ja, darum geht es. Wie bei den anderen Eigenschaften die entfernt wurden, weil sie invers zu weiteren Eigenschaften und damit redundant waren gibt es auch hier möglicherweise die Problematik widersprüchlicher Anforderungen.

Wir sollten nicht bei jeder Eigenschaft einzeln überlegen, wer gerne welche Redundanz hätte, um bestimmte Funktionen einfach umsetzen zu können, oder wen sie stört - und dann auch noch jeweils entscheiden. Wir benötigen dazu eine einheltliche Vorgehensweise. Deshalb lege ich dazu ein neues Issue an.

Mit Linked Data Fragments kann das einfach gelöst werden...

masterDocument (prov:wasDerivedFrom) sollte jedenfalls aus einem einfachen Grund "vorrangig" zu derivativeDocument sein: Die Eigenschaften des Original-Dokuments müssen nicht geändert werden, wenn davon ein weiteres Dokument abgeleitet wird. In dem abgeleiteten Dokument kann man problemlos auf das masterDocument verweisen. Wenn man stattdessen oder zusätzlich die Eigenschaften des Original-Dokuments ändert, dann betrifft diese Änderung ein Objekt welches sich eigentlich nicht geändert hat.

[marians]

Lassen wir bitte mal Linked Data Fragments aus dem Spiel, denn das ist definitiv nicht Teil der OParl Specs 1.0. Und aus meiner Sicht hat es auch wenig Sinn, jetzt darauf zu setzen, dass Du Dich irgendwann nach 1.0 hinsetzt und ein Erweiterungsdokument zu 1.0 formulierst, in dem Linked Data Fragments genutzt werden.

[akuckartz]

Vorläufig in Spezifikation eingearbeitet, mit TODO-Hinweisen. Die grundlegende offene Frage zum Umgang mit inversen Eigenschaften wird in #203 behandelt.