Module für Metadaten

(Auszug aus "Newsfeeds mit RSS und Atom" von Heinz Wittenbrink, erschienen bei Galileo Press, 2005)

RSS 1.0 unterscheidt sich von RSS 2.0 und von Atom dadurch, dass sein Sprachumfang auf den Kern der Sprache begrenzt bleibt. Es bleibt in seiner Ausdruckskraft aber dennoch nicht hinter diesen beiden Vokabularen zurück, denn es ist durch Module beliebig erweiterbar.

Drei Kernmodule oder core modules wurden mit dem RSS 1.0-Vokabular von den Entwicklern des Standards anerkannt. Sie sind Bestandteile der Sprache, wenn sie auch zu anderen Namensräumen gehören. Zahlreiche weitere Module wurden inzwischen vorgeschlagen. Die Modularisierung machte RSS 1.0 zu einem Vorreiter unter den XML-Vokabularen. Erst Jahre später wurden andere XML-Dialekte, z. B. Scalalable Vector Graphics (SVG) und Synchronized Multimedia Interface Language (SMIL), in Module zerlegt.

Der XML-Namensraum-Mechanismus bildet eine der Voraussetzungen dieser Modularisierung. Er allein kann aber die Beziehungen zwischen den verschiedenen Vokabularen nicht definieren. Die Vertreter des Resource Description Formats benutzen immer wieder das Argument, dass sich mit RDF die Beziehungen zwischen verschiedenen Vokabularen explizit und allgemein beschreiben lassen, während ohne RDF die Semantik des kombinierten Vokabulars bei jeder Erweiterung einzeln bestimmt werden müsse. Es gibt registrierte Module von RSS 1.0; darüber hinaus sind auch ad-hoc-Erweiterungen möglich.

RSS 1.0 ermöglicht die Erweiterung des RSS-Grundmodells im Sinne reicherer Metadaten. Die Erweiterung soll aber modular erfolgen, so dass es nicht notwendig ist, den RDF-Kern zu verändern, um die Sprache ausdrucksfähiger zu machen. Die Alternative bestünde darin, neue Elemente in den RSS-Kern aufzunehmen. RSS 1.0 soll vor allem ermöglichen, die Beziehungen zwischen den Elementen in einem Channel oder auch in verschiedenen Channels auszudrücken.

Natürlich können Sie die Erweiterungsmodule von RSS 1.0 auch zusammen mit anderen Syndikationsvokabularen verwenden. Das Dublin Core-Modul wurde bereits erwähnt. Es wird von vielen Aggregatoren unterstützt – auch wenn es mit RSS 2.0 zusammen verwendet wird. Autoren wie Mark Pilgrim empfehlen diese Kombination, weil das Dublin Core-Vokabular präziser definiert und reichhaltiger ist als seine Entsprechungen bei RSS 2.0. Außerdem handelt es sich bei den Dublin Core-Elementen um einen Standard, der inzwischen breit und in sehr unterschiedlichen Gebieten verwendet wird.

Für den Anwendungsentwickler bringt die Kombination von Vokabularen spezifische Probleme mit sich; seine Anwendungen müssen z. B. den Namensraum-Mechanismus beherrschen, wenn Erweiterungsmodule frei genutzt werden sollen. Bei der Entwicklung von Atom entschied man sich dagegen, Dublin Core-Elemente in einem eigenen Namensraum in den Kern des Vokabulars aufzunehmen, um den Umgang mit dem Vokabular zu vereinfachen. Anwender und Benutzer müssen sich bei Atom und RSS nur mit einem einzigen XML-Vokabular beschäftigen, um den größten Teil der Aufgaben erledigen zu können, die sich ihnen in Zusammenhang mit Newsfeeds stellen.

Die Modularisierung von RSS 1.0 hat im Vergleich zu einer Erweiterung folgende Vorteile:

  • Es ist nicht notwendig, die Kernspezifikation immer wieder zu revidieren (dass solche Revisionen notwendig würden, ergibt sich daraus, dass der Anwendungsbereich von RSS sich auch in Zukunft erweitern wird).
  • Es ist kein Konsens über jedes Element bzw. jedes sprachliche Detail erforderlich. Anwendergruppen können die für sie wichtigen Module definieren. RSS kann sich so in einer evolutionären Weise weiterentwickeln.
  • Es kommt nicht zu Konflikten zwischen Nomenklaturen, weil die Bezeichner durch den Namensraum-Mechanismus eindeutig sind.

Bindung der Module an Namensräume

Während RSS 2.0 nur grundsätzlich zulässt, dass Erweiterungsmodule in eigenen Namensräumen definiert werden, legt RSS Regeln für die Entwickler von Modulen fest. Die explizite Regelung eines Verfahrens für die Erweiterung von RSS bedeutet dabei nicht, dass Ad-hoc-Erweiterungen ausgeschlossen sind. Auch sie müssen den Namensraum-Mechanismus verwenden.

Jedes RSS 1.0-Modul ist eine an einen eigenen Namensraum gebundene, abgeschlossene (compartmentalized) Erweiterung. Dabei wird zwischen standardisierten und vorgeschlagenen Modulen unterschieden. Standardisiert wurden allerdings nur das Dublin Core-, das Syndikations- und das Content-Modul. Durch diese Module ist RSS 1.0 im Funktionsumfang RSS 2.0 und seinen Vorgängern überlegen – allerdings ist es auch deutlich komplexer als diese Vokabulare.

Spezifikationsdokumente

Für jedes Modul existiert ein eigenes Spezifikationsdokument unter dem URI "http://purl.org/rss/1.0/modules/". Die Module sollte zusammengehörende Funktionalitäten bündeln und so eng wie möglich definiert sein, ohne dass auf eine zu den übrigen Funktionen gehörende Aufgabe verzichtet werden soll, die der Sache nach nicht von den übrigen Funktionen des Moduls zu trennen ist. Hinter dieser Regel steht das Prinzip, dass viele in ihren Funktionen beschränkte Module leichter zu verwenden und zu verwalten sind als wenige umfangreiche. Die Verfasser des Spezifikationsdokuments sprechen ausdrücklich davon, dass in den Modulen sowohl einfache wie "reiche" Inhaltsmodelle möglich sind. Bei Modulen mit einfachem Inhaltsmodell handelt es sich um Vokabulare, deren Elemente Text, aber keine weiteren XML-Elemente beinhalten.

So ist bei dem jetzt vorhandenen Dublin Core-Modul der Wert der Elemente für Autoren und Kategorien einfach ein String, z. B. <dc:creator>Arthur Autor</dc:creator>. Bei solchen Erweiterungen handelt es sich um property elements. Sie stehen für Eigenschaften, deren Wert ein Literal ist. In einer zukünftigen oder alternativen Version könnte man statt des Literals eine in einem eigenen Personenbeschreibungsmodul definierte Charakterisierung einfügen, z. B.:

<dc:creator>
   <pd:persdes rdf:about="http://www.example.com/authors/ArthurAutor>
      <pd:firstname>Arthur</pd:firstname>
      <pd:lastname>Arthur Autor</pd:lastname>
      <pd:email>arthur@author.com</pd:email>
   <pd:persdes>
</dc:creator> 

Code-Beispiel: Resource als Wert der Eigenschaft dc:creator

RDF-Kompatibilität von Erweiterungen

RSS 1.0 Module sollten so verfasst werden, dass ein RDF-Parser XML-Fragmente, die ihren Regeln entsprechen, in den Graphen integrieren kann, den er beim Parsen eines Dokuments aufbaut. Wenn ein Erweiterungsmodul zu XML führt, das ein RDF-Parser nicht RDF-konform interpretieren kann, dann sollen XML-Parser mit dem Attribut parseType="literal" darauf aufmerksam gemacht werden, dass sie es als einen einzigen Wert verstehen. Der Inhalt eines Elements, das das Attribut parseType mit dem Wert literal hat, wird nämlich so interpretiert wie die Literale, die Sie bereits kennen gelernt haben, z. B. als Werte von title und description. Markup innerhalb des Inhalts eines solchen Elements wird von einem RDF-Parser nicht weiter analysiert – von einem XML-Parser aber durchaus. parseType="literal" ist also so etwas wie ein Trick, mit dem Sie dafür sorgen, dass bestimmte XML-Fragmente in einem XML/RDF-Dokument nicht als RDF verstanden werden. Dieser Trick kann natürlich nur funktionieren, wenn das XML-Fragment, das der Parser als Literal interpretieren soll, der Wert einer Eigenschaft ist. Literale sind in einem RDF-Grafen nur als Objekte erlaubt.

Sie haben bereits gesehen, dass es möglich ist, normales XML als RDF zu interpretieren. Man kann also RDF schreiben, ohne es zu wissen – so wie Monsieur Jourdain in der Molière-Komödie "Der Bürger als Edelmann" Prosa spricht, ohne es zu bemerken. Die Bedingung dafür ist, dass ein Element auf der ersten Ebene eines Dokuments als Ressource (also als Knoten) interpretiert werden kann, ein Element auf der zweiten Ebene als Eigenschaft (also als Kante) und der Inhalt dieses Elements als Wert der Eigenschaft (also entweder wieder als Knoten oder als Literal).

Dieses Verfahren bezeichnet man, wie Sie gesehen haben, auch als striping. Wenn Sie sich an die Abschnitte über blank nodes erinnern, können Sie nachvollziehen, dass ein XML-Parser in einem solchen "gestreiften" Dokument immer dann anonyme Knoten findet, wenn diese nicht durch das Attribut rdf:about einem URI zugeordnet sind. (Zur Striped Syntax und zu blank nodes siehe Die Struktur des Dokuments als Konsequenz des RDF-Modells.)

   

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Newsfeeds mit RSS und Atom bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an: