PROV Ontology berücksichtigen

OParl / spec

Spezifikation für eine offene Schnittstelle für Ratsinformationssysteme

https://oparl.org

Creative Commons Attribution Share Alike 4.0 International

61 stars 21 forks source link

PROV Ontology berücksichtigen #200

Closed akuckartz closed 10 years ago

akuckartz commented 10 years ago

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 commented 10 years ago

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

[x] originator in oparl:Paper entspricht wasAttributedTo (nicht prov:wasGeneratedBy)
[x] masterDocument in oparl:Document entspricht prov:wasDerivedFrom
[x] 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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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