Typos and minor corrections from Sternberg

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

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.

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

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 <http://tools.ietf.org/html/rfc2119>]

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.

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
-

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.
 

src/2-05-objektlisten-und-paginierung.md

@@ -282,14 +282,14 @@ 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`.
 
     https://oparl.example.org/papers/?modified_since=2014-01-01T02%3A00%3A00%2B01%3A00&omit_internal=true
 
 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.

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