Dies ist Version 1 der Spezifikation zu http://www.andonyar.com/rec/
Diese Version wurde durch Version 2 ersetzt
Bis jetzt ist dieses Dokument nur ein Entwurf. Übersetzungen gibt es noch keine.
| Todo | Check |
|---|---|
| Anlegen dieses Dokuments | ✓ |
| Einleitung schreiben | ✓ |
| Strukturierung, Sammeln von Themen | ✓ |
| Festlegung Namensräume | ✓ |
| Festlegung Name der einen Datei | ✓ |
| Komplette Restrukturierung | ✓ |
| Letzte Überprüfung des Regeln-Teils | ✓ |
| Ausformulieren der Begründungen | |
| Diagramme mit Inkscape machen (☺) | |
| Tabelle mit Fragen vervollständigen | |
| Aufräumen | |
| ... | |
| Übersetzung ins Englische |
Auf Andonyar werden voraussichtlich verschiedene Dokumente publiziert. Diese Publikationen sollen einige minimale Regeln befolgen. Ziel ist es, die Dokumente klassifizieren und durchsuchen zu können. Dazu müssen die Publikationen mit Metainformationen versehen werden, die von Computern verstanden werden können. Weiter sollen die Publikationen eine gewisse Qualität erreichen. Andererseits sollen die Regeln aber auch so kurz wie möglich sein, denn jede Publikation hat ihre eigenen Erfordernisse.
Was Metainformationen, die von Computern verstanden werden
können
und Qualität der Publikationen
in diesem Kontext
bedeuten, soll im weiteren näher beschrieben werden.
/rec/ hortet öffentliche, statische Publikationen aller Art.
Hier sind die Regeln so kurz wie möglich auf den Punkt gebracht. Publikationen in /rec/ müssen alle Regeln aus diesem Kapitel erfüllen. Die detailierten Begründungen, die nach diesem Kapitel folgen, sind dafür unwichtig, was das prüfen und erstellen von konformen Publikationen erleichtert.
Grundsätzlich reserviert andonyar den Namensraum http://u.andonyar.com/ für Dinge, die nicht über das Internet übertragen werden können.
Folgende Namensräume werden in dieser Spezifikation gebraucht:
| Kürzel | Namensraum | Dokumentation |
|---|---|---|
| agv | http://u.andonyar.com/ageneralvoc/ | Namensräume von Andonyar |
| dc | http://purl.org/dc/elements/1.1/ | Dublin Core |
| dcterms | http://purl.org/dc/terms/ | Dublin Core |
| rdf | http://www.w3.org/1999/02/22-rdf-syntax-ns# | RDF-Schema zu diesem Namensraum |
Jede Publikation befindet sich in einem eigenen Ordner. Der Name dieses Verzeichnisses hat die Struktur /rec/JJJJ-MM/Publikationsname/. JJJJ-MM bezeichnen das Jahr und den Monat an dem die Publikation in /rec/ aufgenommen wurde. Der Publikationsname kann für jede Publikation frei gewählt werden.
Die URI der Publikation lautet dann http://www.andonyar.com/rec/JJJJ-MM/Publikationsname/. Der / am Schluss ist zwingend. Er muss immer dabei sein, wenn man auf die Publikation als ganzes verweist.
Der Ordner der Publikation selbst kann im Prinzip beliebig aussehen. Die Namen der Dateien dürfen nicht mit einem Punkt beginnen. (Dateien mit Punkt am Anfang des Namens werden vom Server versteckt und dienen oft dazu, den Server zu konfigurieren. Ein Beispiel dazu ist .htaccess) Nicht fehlen darf natürlich die Datei A.rdf mit den Metadaten. Eine weitere spezielle Datei ist index.*. (Der Server macht Content-Negotiation über alle Dateien, die mit index. beginnen.) Diese Datei wird vom Server als Index geschickt.
URIs sollten sich nicht ändern. Werden Resourcen entfernt oder umbenannt, sollte der Webserver so konfiguriert werden, dass er die richtigen Fehlercodes zurückgibt. Wird eine Publikation ganz entfernt, mutiert das Sollen zum Müssen.
Im Stammverzeichnis der Publikation (/rec/JJJJ-MM/name/) muss jede Publikation die Datei A.rdf enthalten. Diese Datei muss von Typ application/rdf+xml sein und http://www.w3.org/TR/rdf-syntax-grammar/ entsprechen. Diese Datei wird möglicherweise automatisch verarbeitet. Sie darf verschiedene Resourcen der Publikation beschreiben. Weiter dürfen Resourcen der Publikation darauf verweisen (z.B. mit einem Link-Element im head eines HTML-Dokuments). Die Datei muss aber ein Minimum an Metainformationen enthalten, die im weiteren genannt werden.
Metainformationen, die die gesamte Publikation betreffen, wie sie im weiteren gefordert werden, müssen immer der Resource /rec/JJJJ-MM/name/ zugewiesen werden.
Es muss immer angegeben werden, welche Version dieser Spezifikation von der Publikation eingehalten wird. Dies geschieht mit dem Prädikat agv:aspec.
Folgende Trippel müssen präsent sein. Ihr Subjekt ist jeweils die Publikation.
Folgende Trippel sind empfohlen: dcterms:created, dcterms:modified, dcterms:dateCopyrighted
Ein Publikationszyklus ist zur Zeit nicht vorgesehen. Es ist natürlich möglich für einzelne Pulbikationen einen angepassten Zyklus zu verwenden. Allerdings müssen alle Angaben in A.rdf immer wahr sein.
In Zukunft soll es möglich sein, Updates der Publikation in A.rdf mit einem Kommentar und weiteren Details zu vermerken. Diese Informationen könnten dann z.B. auf der Homepage von Andonyar präsentiert werden. Allerdings können bereits jetzt folgende Prädikate verwendet werden: dc:date dcterms:created dcterms:modified.
Jede Publikation in /rec/ muss mit genau einem agv:licenseCategory auf eine der unten aufgeführten Lizenzkategorien verweisen.
Sollten Teile der Publikation unter veschiedene der obigen Lizenzkategorien fallen, so ist diejenige zu verwenden, die am wenigsten Freiheiten lässt.
agv:LicenseFree sollte mehr oder weniger den DFSG von Debian gehorchen. Es muss aber nicht genau übereinstimmen.
Es ist empfehlenswert mit dcterms:license die Lizenz näher zu beschreiben.
Weiter muss der Urheber mit dcterms:rightsHolder angegeben werden.
Diese Spezifikation macht in dieser Hinsicht keine Regeln. Es soll darauf geachtet werden, dass Publikationen möglichst für alle zugänglich sind und sich an Standards (z.B. vom W3C) orientieren. Entscheidungen zu diesem Thema werden sich in anderen Andonyar-Spezifikationen finden.
Hier einige Beispiele:
Die Datei .htaccess im Stammverzeichnis der Publikation kann benutzt werden um die im Folgenden genannten Konfigurationen des Apache-Webservers vorzunehmen. In Unterverzeichnissen der Publikation dürfen keine .htaccess-Dateien sein, es ist nur diejenige im Stammverzeichnis erlaubt.
Man kann nicht davon ausgehen, dass die .htaccess Dateien für immer unterstützt werden. Vielleicht werden sie später durch Angaben in der A.rdf-Datei erstetzt. Das Benutzen einer .htaccess-Datei ist ausser für die oben Besprochenen Zwecke untersagt. Insbesondere sind Zugriffseinschränkungen (nach Passwort, Domain, IP usw.) verboten.
Annotationen werden durch andere Mechanismen verwaltet.
Hier sind meine genauen Begründungen zu den Regeln. Hier dokumentiere ich, wie ich die jeweiligen Entscheidungen getroffen habe.
Ziel ist es, dass sich URLs nicht verändern. Deshalb erscheint auch das Publikationsdatum in der URL. So können Namenskollisionen und Namensänderungen vermieden werden. Das Datum in der URL hat ansonsten keine weitere Bedeutung. Auch Publikationen mit altem Datum in der URL können aktuell sein.
Nocheinmal: URLs sollen sich nicht ändern. Das verschieben oder netfernen von Publikationen soll vermieden werden. Sollte es trotzdem einmal nötig werden, dann muss der Webser so konfiguriert werden, dass er die richtigen Fehlercodes und Weiterleitungen zurück gibt. (Wird also eine Publikation entfernt oder verschoben, muss das alte Verzeichnis bestehen bleiben, worin sich nur die .htaccess-Datei befindet, die für die richtigen Fehlercodes sorgt!)
Argumente dafür, dass der / zum Resourcenname gehört: 1. betrachte es als Namensraum. 2. Wenn man den Webserver ohne schliessendes / frägt, sagt er 301 Moved Permanently. 3. Für die Indexseite könnte man direkt ihren Content-Name (idex*) verwenden, sollte man sie speziell beschreiben wollen.
Argumente dagegen: 1. Mit / am Ende steht eigentlich für die Indexseite, nicht für das gesamte Verzeichnis.
Lösung: / gehört zum Resourcennamen. Will man vom Server die Resource selbst, gibt er die Indexseite zurück, denn was soll er sonst tun. (Downloaden der Resource mit tar oder ähnlich wird vielleicht über ,-Tools realisiert werden.
Lösung: Es wird ein dc:conforms_to verwendet, denn andere Applikationen kennen es. In der Datenbank sind die Spezifikationen von Andonyar beschrieben. Man kann also durch eine einfache RDQL-Abfrage die richtigen dc_conforms_tos finden.
Änderung: Manche Leute ändern ihre Meinung ziemlich oft. Ich gehöre auch zu denen. RDF-Schema ermöglicht es, für Predikate "Unterprädikate" zu definieren. Das könnte ich auch hier tun und ein Unterprädikat im Andonyar-Namensraum für dc:conforms_to definieren und dann mit diesem auf die Spezifikation zeigen. Dies hat den genialen Vorteil, dass ich jederzeit die Assoziation zu dc:conforms_to entfernen kann. Der Vorteil, dass andere Programme dc:conforms_to kennen geht nicht verloren, wenn ich das RDF-Schema dazu schreibe und die anderen Programmen die notwendige Überlegung machen können.
Zuerst wollte ich einen Publikationszyklus verwenden, bei dem die Angaben in der RDF-Datei wie Validität, Accessibility zeitweise noch nicht sichergestellt sind. Dies erachte ich jetzt als Unsinn. Die Angaben in der RDF-Datei müssen immer wahr sein.
Die Idee ist es, dass Programme von Andonyar selbst feststellen können, was mit einer Publikation gemacht werden darf. So könnte ich zum Beispiel eine Programm schreiben, das alle freien Publikationen auf eine CD schreibt.
Man kann nicht davon ausgehen, dass die .htaccess Dateien für immer unterstützt werden. Vielleicht werden sie später durch Angaben in der A.rdf-Datei erstetzt. So könnte man problemlos die Mime-Types in A.rdf angeben und dann von einem Skript die entsprechende .htaccess-Datei generieren lassen. So weit bin ich aber noch nicht ganz. Das Benutzen einer .htaccess-Datei ist also ausser für die oben Besprochenen Zwecke untersagt. Insbesondere sind Zugriffseinschränkungen (nach Passwort, Domain, IP usw.) verboten.
Werte der zweiten Spalte: norm (die Antwort befindet sich im normativen Teil dieses Dokuments), inform (die Antwort ist ist nur eine zusätzliche Information), kein (in diesem Dokument gibt es dazu keine Antwort.
| Frage | Dokumentteil | Ort der Antwort |
|---|
Folgende Dinge muss ich mir überlegen:
Dazu einige Beispiele:
Ein Skript könnte automatisch ein RSS-Feed erzeugen, wenn eine neue Publikation hinzukommt, oder sich an einer bestehenden etwas ändert.
Spezielle Informationen über ein Dokument könnte dynamisch erzeugt werden (Komma-Tools)
Dokumente können von Benutzern kommentiert werden, mit Hilfe eines Systems wie annotea (siehe daco w3c).