search

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

Einheitlich singular statt plural #129

Closed akuckartz closed 10 years ago

akuckartz commented 10 years ago

Konvention: Attributnamen sollten einheitlich singular statt plural sein.

sterni24 commented 10 years ago

@akuckartz Was sind Attributnamen?

akuckartz commented 10 years ago

@sterni24 Namen von Eigenschaften, also z.B. "meeting" (statt "meetings"), "paper" (statt "papers") etc.

Die Vereinheitlichung der Terminologie in der Spezifikation ist auch noch eine Aufgabe (mit Properties, Eigenschaften, Attributen ist das selbe gemeint).

sterni24 commented 10 years ago

@akuckartz OK, dann meinen wird das Gleiche. Ich hatte das im Beitrag #117 schon einmal in ähnlicher Richtung angeregt:

'Da das Ganze auch irgendwann programmiert werden muss, wäre es eine weitere Optimierung, wenn die Objektbezeichnungen gemäß den URL-Pfaden angepasst würden oder umgekehrt. Beispiel: oparl:Person -> oparl:person "http://oparl.beispielris.de/bodies/0/person/" oder oparl:Person -> oparl:peoples "http://oparl.beispielris.de/bodies/0/peoples/"'

Im Hinblick auf die Verwendung der URLs sollte hier die Empfehlung ihrerseits ausgesprochen werden, die selben Namen (lt. Ihrem Vorschlag "singular") zu verwenden. Das würde ich auch so konsequent in den Beispielen durchziehen!

akuckartz commented 10 years ago

@sterni24 Bezüglich der Beispiele der Hinweis, dass ich für einen Anhang der Spezifikation die Erstellung eines vollständigen zusammenhängenden Satzes von Objekten einer nicht existierenden Kommune plane (oder einer Kommune die kein kommerzeil vertriebenes RIS verwendet). Das wird aber voraussichtlich erst im Laufe des Mai 2014 erfolgen.

akuckartz commented 10 years ago

Ist in den Abschnitten 8xxx eingearbeitet. Deshalb schliesse ich dieses Issue.

sterni24 commented 10 years ago

@akuckartz Sie können sich auch gern an unserer Musterstadt versuchen!

marians commented 10 years ago

Ich muss sagen, ich finde das furchtbar, wenn die Eigenschaft einer Körperschaft, die auf alle Sitzungen zeigen soll, "meeting" statt "meetings" heißt und alle Mitglieder einer Gruppierung "participant" statt "participants". Das ist gegen jede Intuition.

Ich möchte das rückgängig machen.

akuckartz commented 10 years ago

Eine erste schnelle Antwort mit ein paar unsortierten Gründen:

Ich werde das aber noch ausführlicher (und hoffentlich verständlicher) begründen.

marians commented 10 years ago

Mag sein, dass man das in relationalen Datenbanken so machen würde. Da werden 1:n Beziehungen ja auch über einen Fremdschlüssel modelliert, der auf genau ein Objekt zeigt. Das lässt sich nicht gut übertragen. Tabellennamen hingegen werden gerne "documents", "posts", "comments" genannt, seltener "document", "post", "comment".

Wenn ich beispielsweise in einer Dokumenten-DB einen Blogbeitrag modellieren will, nenne ich die Tags-Eigenschaft "tags" und nicht "tag". Und die Kommentare heißen "comments" und nicht "comment". Aus Tutorials und Artikeln kann ich bestätigen, dass andere das ebenso machen.

ORM-Bibliotheken, beispielsweise für Ruby on Rails (AcitveRecord) oder für Python (SQLAlchemy), geben sich große Mühe, Objekt-Eigenschaften, die in der relationalen Datenbank mit Singular-Bezeichnung stehen, zu pluralisieren. Das machen sie, damit es ein Entwickler leichter hat, mit dem Objekt zu arbeiten.

Im Sinne der Selbstbeschreibungsfähigkeit bin ich weiterhin dafür, dort Plural anzuwenden, wo die Eigenschaft eine Liste von Objekten ist.

akuckartz commented 10 years ago

In Graph-Datenbanken ist es noch einfacher als bei relationalen Datenbanken - und entsprechend in den Linked Data und JSON-LD Welten. Auch aufgrund der Verwendung von org:Organization käme es zu Inkonsistenzen, denn darin wird durchgehend Singular verwendet.

Ein Beispiel anhand von "member" / "members".

In einem Tripel financialCommittee member John_Doe ist die Eigenschaft immer Singular, nie plural.

Dies:

"@id": "einKleinesGremium",
"member": "marian",

ist "nur" eine kompakte Schreibweise für ein Tripel:

"einKleinesGremium" "member" "marian"

während dies:

"@id": "einKleinesGremium",
"member": [ "marian", "andreas"],

"nur" eine kompakte Schreibweise für diese zwei Tripel ist (deren Reihenfolge irrelevant ist):

"einKleinesGremium" "member" "marian" .
"einKleinesGremium" "member" "andreas"

Es gibt keinen Unterschied zwischen

"@id": "einKleinesGremium",
"member": "marian",

und

"@id": "einKleinesGremium",
"member": ["marian"],

D.h. das an der einen Stelle eine JSON-Liste steht und an der anderen nicht ist nur eine Frage der Schreibweise. Der Gehalt an Daten und Informationen ist identisch.

Ich bin sehr für Selbstbeschreibung und da auch im Rahmen von #18 dran. Aber die Verwendung von Plural würde das wirklich nicht fördern. Ich habe mich davon allerdings auch erst vor ein paar Wochen überzeugt.

akuckartz commented 10 years ago

@marians Ich reiche das Issue an dich weiter. Meine Haltung habe ich ja erklärt, dass sie nachvollziehbar ist hoffe ich.

Wie auch immer das Ergebnis aussieht: da sich mehrere Welten mit unterschiedlichen und gut begründeten Konventionen überlappen ist es unvermeidbar, dass es zu Konventions- oder Regelbrüchen kommen wird. (Mit Rechts- oder Linksverkehr ist das insoweit nicht vergleichbar, denn die Regeln dafür sind beide nicht gut begründet - wenn überhaupt.)

akuckartz commented 10 years ago

Ein Beispiel auf das ich bei der Suche nach etwas anderem (zusätzliches Angebot von einfachem JSON) gestoßen bin. Metadaten der US Regierung: http://project-open-data.github.io/schema/

Auch dort wird durchgängig Singular verwendet, mit der interessanten aber korrekten Ausnahme von 'references'.

akuckartz commented 10 years ago

Es gibt hierfür wahrscheinlich eine ziemlich einfache Lösung, die eine JSON-LD Serialisierung mit Plural-Formen ermöglicht und gleichzeitig auf einer Singular-Form für RDF aufbaut - und zudem die Komplexität fast nicht vergrößert. Dies wird offenbar auch von Popolo so gemacht.

akuckartz commented 10 years ago

Der Vollständigkeit halber ein entsprechendes Issue der Hydra CG, die zunächst Plural für Eigenschaften verwendet hatte, aber dann einstimmig zu Singular gewechselt ist: https://github.com/HydraCG/Specifications/issues/25

akuckartz commented 10 years ago

Die beiden scheinbar unvereinbaren Anforderungen können mittels Kontext gleichzeitig erfüllt werden. Die Eigenschaft org:hasMembership kann in dem JSON-LD Kontext z.B. als memberships serialisiert werden. Bei einer Deserialisierung, wie sie in Clients bei der Konvertierung in RDF-Tripel erfolgt, wird dann automatisch die Singular-Form verwendet. Wer stattdessen die Plural-Form bevorzugt, der erhält diese in dem JSON-LD-Dokument als Eigenschaftsname. Damit erhalten die beiden Gruppen von Anwendungs-Entwicklern nahezu automatisch die jeweils bevorzugte Form.

akuckartz commented 10 years ago

Hier gibt es nichts mehr zu tun.