From fbdc221933a53284b4501b4f692ec14ace2a79ee Mon Sep 17 00:00:00 2001 From: konstin Date: Thu, 24 May 2018 22:47:28 +0200 Subject: [PATCH] Typos and minor corrections from Sternberg --- .../1-03-transparenz-und-beteiligung-durch-open-data.md | 2 +- schema/strings.yml | 4 ++-- src/1-03-transparenz-und-beteiligung-durch-open-data.md | 2 +- src/1-05-nomenklatur.md | 2 +- src/1-06-datenschutz.md | 4 ++-- src/1-08-oparl-autoren.md | 4 ++-- src/2-03-urls.md | 4 ++-- src/2-05-objektlisten-und-paginierung.md | 4 ++-- src/4-01-oparl-1-1.md | 8 ++++---- 9 files changed, 17 insertions(+), 17 deletions(-) diff --git a/locales/en/src/1-03-transparenz-und-beteiligung-durch-open-data.md b/locales/en/src/1-03-transparenz-und-beteiligung-durch-open-data.md index 549f7b5..db00b0e 100644 --- a/locales/en/src/1-03-transparenz-und-beteiligung-durch-open-data.md +++ b/locales/en/src/1-03-transparenz-und-beteiligung-durch-open-data.md @@ -43,7 +43,7 @@ Einhaltung der technischen Prinzipien, noch der weiteren Open-Data-Prinzipien vo garantieren. Viele Bestandteile der OParl-Spezifikation, die einen weitgehend barrierearmen Zugang zu Informationen[^1] ermöglichen sollen, sind in der vorliegenden Version noch optional (Beispiel: Volltexte von Dokumenten über -die API abrufbar machen). Andere Bestandteile,die von Interesse wären, sind +die API abrufbar machen). Andere Bestandteile, die von Interesse wären, sind noch gar nicht von OParl abgedeckt (Beispiel: Abstimmungsergebnisse). Grund dafür ist, dass sich OParl in einem frühen Stadium befindet und primär am Status Quo der parlamentarischen Informationssysteme ausgerichtet ist. Es liegt also auch weiterhin an diff --git a/schema/strings.yml b/schema/strings.yml index 0a8e70e..4ef9a4f 100644 --- a/schema/strings.yml +++ b/schema/strings.yml @@ -83,7 +83,7 @@ de: Objekte vom Typ `oparl:File` können unter anderem mit Drucksachen (`oparl:Paper`) oder Sitzungen (`oparl:Meeting`) in Beziehung stehen. Dies wird durch die Eigenschaft `paper` bzw. `meeting` angezeigt. Mehrere Objekte vom Typ `oparl:File` können mit einander in direkter Beziehung stehen, z.B. wenn sie den selben Inhalt in unterschiedlichen technischen Formaten wiedergeben. Hierfür werden die - Eigenschaften `masterFile` bzw. `derivativeFile` eingesetzt. Das sgezeigte Beispiel-Objekt repräsentiert eine PDF-Datei + Eigenschaften `masterFile` bzw. `derivativeFile` eingesetzt. Das gezeigte Beispiel-Objekt repräsentiert eine PDF-Datei (zu erkennen an der Eigenschaft `mimeType`) und zeigt außerdem über die Eigenschaft `masterFile` an, von welcher anderen Datei es abgeleitet wurde. Umgekehrt **kann** über die Eigenschaft `derivativeFile` angezeigt werden, welche Ableitungen einer Datei existieren. File.properties.name.description: "Ein zur Anzeige für Endnutzer bestimmter Name für dieses Objekt. Leerzeichen **dürfen** enthalten sein, Datei-Endungen wie \".pdf\" **sollten nicht** enthalten sein." @@ -185,7 +185,7 @@ de: Organization.properties.website.description: Allgemeine Website der Gruppierung. Organization.properties.location.description: Ort, an dem die Organisation beheimatet ist Organization.properties.externalBody.description: Externer OParl Body, der dieser Organisation entspricht. Diese Eigenschaft ist dafür gedacht auf eventuelle konkretere OParl-Schnittstellen zu verweisen. Ein Beispiel hierfür wäre eine Stadt, die sowohl ein übergreifendes parlamentarisches Informationssystem, als auch bezirksspezifische Systeme hat. - Membership.description: Über Objekte diesen Typs wird die Mitgliedschaft von Personen in Gruppierungen dargestellt. Diese Mitgliedschaften können zeitlich begrenzt sein. Zudem kann abgebildet werden, dass eine Person eine bestimmte Rolle bzw. Position innerhalb der Gruppierung inne hat, beispielsweise den Vorsitz einer Fraktion. + Membership.description: Über Objekte dieses Typs wird die Mitgliedschaft von Personen in Gruppierungen dargestellt. Diese Mitgliedschaften können zeitlich begrenzt sein. Zudem kann abgebildet werden, dass eine Person eine bestimmte Rolle bzw. Position innerhalb der Gruppierung innehat, beispielsweise den Vorsitz einer Fraktion. Membership.properties.person.description: Rückreferenz auf Person, welches nur dann ausgegeben werden muss, wenn das Membership-Objekt einzeln abgerufen wird, d.h. nicht Teil einer internen Ausgabe ist. Membership.properties.organization.description: Die Gruppierung, in der die Person Mitglied ist oder war. Membership.properties.role.description: Rolle der Person für die Gruppierung. Kann genutzt werden, um verschiedene Arten von Mitgliedschaften zum Beispiel in Gremien zu unterscheiden. diff --git a/src/1-03-transparenz-und-beteiligung-durch-open-data.md b/src/1-03-transparenz-und-beteiligung-durch-open-data.md index f2d58d8..b7ee9fb 100644 --- a/src/1-03-transparenz-und-beteiligung-durch-open-data.md +++ b/src/1-03-transparenz-und-beteiligung-durch-open-data.md @@ -43,7 +43,7 @@ Einhaltung der technischen Prinzipien, noch der weiteren Open-Data-Prinzipien vo garantieren. Viele Bestandteile der OParl-Spezifikation, die einen weitgehend barrierearmen Zugang zu Informationen[^1] ermöglichen sollen, sind in der vorliegenden Version noch optional (Beispiel: Volltexte von Dokumenten über -die API abrufbar machen). Andere Bestandteile,die von Interesse wären, sind +die API abrufbar machen). Andere Bestandteile, die von Interesse wären, sind noch gar nicht von OParl abgedeckt (Beispiel: Abstimmungsergebnisse). Grund dafür ist, dass sich OParl in einem frühen Stadium befindet und primär am Status Quo der parlamentarischen Informationssysteme ausgerichtet ist. Es liegt also auch weiterhin an diff --git a/src/1-05-nomenklatur.md b/src/1-05-nomenklatur.md index f7572e9..70d74d9 100644 --- a/src/1-05-nomenklatur.md +++ b/src/1-05-nomenklatur.md @@ -2,7 +2,7 @@ ### Zwingende, empfohlene und optionale Anforderungen {#muss_sollte_darf} -Dieses Spezifikation nutzt **müssen**, **können** und **sollten** +Diese Spezifikation nutzt **müssen**, **können** und **sollten** in einer eindeutig definierten Art und Weise. Diese ist angelehnt an die Definitionen der Begriffe MUST, SHOULD und MAY (bzw. MUST NOT, SHOULD NOT und MAY NOT) aus RFC2119.^[RFC2119 ] diff --git a/src/1-06-datenschutz.md b/src/1-06-datenschutz.md index df4db7a..1b81e4c 100644 --- a/src/1-06-datenschutz.md +++ b/src/1-06-datenschutz.md @@ -7,7 +7,7 @@ Datenschutz-Gesetzgebung zu beachten. Um personenbezogene Daten zu veröffentlichen, ist üblicherweise eine explizite Zustimmung der betroffenen Person erforderlich. Dies gilt für die bestehende Weboberfläche des Ratsinformationssystems ebenso wie für die OParl- -Schnittstelle. Eine besondere Beachtung sollten hierbei unter anderem E-Mail- -Adressen, Anschriften, Fotos und Anwesenheitslisten finden. Es wird +Schnittstelle. Besonders zu beachten sind hierbei unter anderem E-Mail- +Adressen, Anschriften, Fotos und Anwesenheitslisten. Es wird empfohlen, vor Veröffentlichung über die Schnittstelle den zuständigen Datenschutzbeauftragten zu kontaktieren. diff --git a/src/1-08-oparl-autoren.md b/src/1-08-oparl-autoren.md index 52c6a06..09f4fc8 100644 --- a/src/1-08-oparl-autoren.md +++ b/src/1-08-oparl-autoren.md @@ -28,9 +28,9 @@ Marianne Wulff(\*) Folgende Personen haben an OParl 1.1 mitgewirkt: grindhold -Medo42 +Simeon Maxein Sami Mussbach +Ralf Sternberg (\*): Initiator(in), (\*\*): bis 4.7.2014 - diff --git a/src/2-03-urls.md b/src/2-03-urls.md index 5a033a6..632047f 100644 --- a/src/2-03-urls.md +++ b/src/2-03-urls.md @@ -28,7 +28,7 @@ werden, dass sie nur über eine bestimmte Domain erreichbar sind. OParl-Server * Wenn ein Server auch durch eine nicht-kanonische URL erreichbar ist, dann **sollte** eine entsprechende HTTP-Anfrage mit einer Weiterleitung auf die entsprechende kanonische URL und HTTP-Status-Code 301 beantwortet werden. -Zur überprüfung kann z.B. der `Host`-Header einer HTTP-Anfrage verwendet werden. +Zur Überprüfung kann z.B. der `Host`-Header einer HTTP-Anfrage verwendet werden. Beim Pfad-Bestandteil der URL **müssen** Server-Implementierer darüber hinaus beachten, dass zur kanonischen Schreibweise auch die Groß- und Kleinschreibung, die Anzahl von Schrägstrichen als Pfad-Trennzeichen und die Anzahl von führenden Nullen vor numerischen URL-Bestandteilen gehört. @@ -72,7 +72,7 @@ die nicht verändert werden. Ändert sich beispielsweise die Kennung einer Drucksache im Verlauf ihrer Existenz, dann scheidet sie für die Bildung der URL aus. -Des weiteren sollen Eigenschaften der Implementierung nicht sichtbar sein. +Des Weiteren sollen Eigenschaften der Implementierung nicht sichtbar sein. Ist ein OParl-Server beispielsweise in PHP geschrieben, **sollte** dies **nicht** dazu führen, dass im Pfad ein Bestandteil wie "oparl.php/" erscheint. diff --git a/src/2-05-objektlisten-und-paginierung.md b/src/2-05-objektlisten-und-paginierung.md index ee2f121..e1ec775 100644 --- a/src/2-05-objektlisten-und-paginierung.md +++ b/src/2-05-objektlisten-und-paginierung.md @@ -282,7 +282,7 @@ Drucksachen herunterladen und in einer Datenbank speichern. https://oparl.example.org/papers/ -Um den Datenbestand am nächsten Tag zu aktualisieren, ruft der Client die selbe +Um den Datenbestand am nächsten Tag zu aktualisieren, ruft der Client dieselbe URL auf, diesmal jedoch mit dem Parameter `modified_since` mit dem Wert `2014-01-01T02:00:00+01:00` und mit `omit_internal`. @@ -290,6 +290,6 @@ URL auf, diesmal jedoch mit dem Parameter `modified_since` mit dem Wert Diese Liste ist in der Regel deutlich kürzer als die Liste aller Objekte, sodass die Aktualisierung bedeutend schneller ist als der erste Abruf. Der -Client muss außerdem nur noch eine deutlich kleiner Menge an Objekten in die +Client muss außerdem nur noch eine deutlich kleinere Menge an Objekten in die Datenbank einfügen, aktualisieren oder löschen, um den gleichen Datenstand wie der Server zu haben. diff --git a/src/4-01-oparl-1-1.md b/src/4-01-oparl-1-1.md index 41422e0..306a30e 100644 --- a/src/4-01-oparl-1-1.md +++ b/src/4-01-oparl-1-1.md @@ -9,14 +9,14 @@ OParl 1.1 gering gehalten. OParl 1.0 wurde in der Annahme geschrieben, dass für sechs Objekttypen (LegislativeTerm, Membership, AgendaItem, Consultation, File, Location) keine verlässlichen Werte für `created` und `modified` existieren. - Aus diesem Grund hatten wir uns für das Design mit eingebetten Objekten + Aus diesem Grund hatten wir uns für das Design mit eingebetteten Objekten entschieden. Da sich nun jedoch herausgestellt hat, dass `created` und `modified` bei allen Objekten existieren, können auch für alle Objekte Listen angeboten werden. Das bringt bei große Vereinfachungen für Clients bei der Synchronisation. Konkret sind `created` und `modified` in OParl 1.1 für alle Objekte zwingend -und es gibt fünf neue externe Objektlisten in Body: AgendaItem, Consultation, +und es gibt sechs neue externe Objektlisten in Body: AgendaItem, Consultation, File, LegislativeTerm, Location und Membership. Das Attribut für die Location-Liste in Body heißt dabei `locationList`, um eine Kollision mit dem bereits existierenden `location` zu vermeiden. Das gleiche gilt auch für @@ -28,12 +28,12 @@ neuen externen Listen, die die bisher eingebetteten Objekte extern ausgeben. Diese Redundanz lässt sich auf Grund der Semver-Regeln in Version 1.1 nicht vermeiden und kann erst in einer Version 2 beseitigt werden. Um diese Redundanz zumindest bei der Aktualisierung eines lokalen Datenbestands vermeiden zu können -wurde die URL-Paramter `omit_internal` eingeführt. +wurde die URL-Parameter `omit_internal` eingeführt. ### Weitere Änderungen * Namespace-URLs werden durchgängig im Camel Case geschrieben * Externe Objektlisten können ein `web` Attribut angeben - * Jedes Objekt des Schema hat seine eigene Datei bekommen + * Jedes Objekt des Schemas hat seine eigene Datei bekommen * Definition eines Fehlerobjektes für die Ausnahmebehandlung * sha1 veraltet und sha512 als Ersatz hinzugefügt. (s. https://shattered.io) * Die Rückreferenz von Location auf Person wird zusätzlich auch noch