The problem Ross issued is that there is little coordination and each standard governs its own registry of data format identifiers. An inofficial registry for unAPI [archive] disappeared (that’s why I started the discussion), there is a registry for SRU, a registry for OpenURL, and a list for Jangle. In OAI-PMH and unAPI each service hosts its own list of formats, OAI-PMH includes a method to map local identifier to global identifiers.

On code4lib several arguments and suggestions where raised which almost provoced me to a rant on library standards in general (everyone want’s to define but noone likes to implement and reuse. Why do librarians ignore W3C and IETF?). Identifiers for data formats should neither be defined by creators of transport protocols nor do we need yet another über-registry. In my point of view the problem is less technical but more social. Like Douglas Campbell writes in Identifying the identifiers, one of the rare papers on identifier theory: it’s not a technology issue but a commitment issue.

First there is a misconception about registries of data format identifiers. You should distinguish descriptive registries that only list identifiers and formats that are defined elsewhere and authoritative registries that define identifiers and formats. Yes: and formats. It makes no sense to define an identifier and say that is stands for data format X if you don’t provide a specification of format X (either via a schema or via a pointer to a schema). This already implies that the best actor to define a format identifier is the creator of the format itself.

Second local identifiers that depend on context are always problematic. There is a well-established global identifier system called Uniform Resource Identifier (URI) and there is no excuse not to use URIs as identifiers but incapability, dullness, laziness, or ignorance. The same reasons apply if you create a new identifier for a data format that already has one. One good thing about URI is that you can always find out who was responsible for creating a given identifier: You start with the URI Scheme and drill down the namespaces and standards. I must admin that this process can be laborious but at least it makes registries of identifiers descriptive for all identifiers but the ones in their own namespace.

Third you must be clear on the definition of a format. For instance the local identifier “MARC” does not refer to a format but to many variants (USMARC, UNIMARC, MARC21…) and encodings (MARCXML/MARC21). This is not unusual if you consider that many formats are specializations of other formats. For instance ATOM (defined by RFC4287 and RFC5023, identified either its Mime Type “application/atom+xml” which can could expressed as URI http://www.iana.org/assignments/media-types/application/atom%2Bxml or by its XML Namespace “http://www.w3.org/2005/Atom”)* is extended from XML (specified in http://www.w3.org/TR/xml [XML 1.0] and http://www.w3.org/TR/xml11 [XML 1.1], identified by this URLs or by the Mime Type “application/xml” which is URI http://www.iana.org/assignments/media-types/application/xml)*.

The problem of identifying the right identifiers for data formats can be reduced to two fundamental rules of thumb:

1. reuse: don’t create new identifiers for things that already have one.

2. document: if you have to create an identifier describe its referent as open, clear, and detailled as possible to make it reusable.

If there happen to exist multiple identifiers for one thing, choose the one that is documented and adopted best. There will always be multiple identifiers for the same thing – don’t make it worse.

*Footnote: The identification of Internet Media Types with URIs that start with http://www.iana.org/assignments/media-types/ is neither widely used nor documented well but it’s the most official URI form that I could find. If for a particular format there is a better identifier – like an XML or RDF namespace – then you should use that, but if there is nothing but a Mime Type then there is no reason to create a new URI on your own.

Ich halte es zumindest für wichtig, in etwa auf dem Laufenden zu sein und bei Bedarf zu versuchen, Einfluss zu nehmen, falls die Entwicklung völlig an den eigenen Bedürfnissen vorbeigeht. So ganz verstanden habe ich Jangle allerdings bisher noch nicht. Statt eine neue Gesamt-API zu entwickeln, sollte meiner Meinung nach besser bei den existierenden Schnittstellen aufgeräumt werden – anschließend können diese dann ja in Jangle o.Ä. zusammengefasst werden.

Larry stellt Jangle und Primo gegenüber: auf der einen Seite der systematische OpenSource-Ansatz, in den man sich erstmal einarbeiten muss und der dafür insgesamt effizienter und flexibler ist und auf der anderen Seite das teure, unflexible Gesamtprodukt, das dafür schick aussieht. Leider geht es bei den Entscheidungsträgern meist primär um die Fassade, so dass sich OpenSource nur langsam (aber sicher) durchsetzt.

On the one hand I welcome if vendors try to agree on (open) standards and service oriented architecture. On the other hand the working group is yet another top-down effort to discuss things that just have to be implemented based on existing Internet standards.

1. Harvesting: In the library world this is mainly done via OAI-PMH. I’d also consider RSS and Atom. To fetch single records, there is unAPI – which the DLF group does not mention. There is no need for any other harvesting API – missing features (if any) should be integrated into extensions and/or next versions of OAI-PMH and ATOM instead of inventing something new. P.S: Google Wave shows what to expect in the next years.

2. Search: There is still good old overblown Z39.50. The near future is (slightly overblown) SRU/SRW and (simple) OpenSearch. There is no need for discussion but for open implementations of SRU (I am still waiting for a full client implementation in Perl). I suppose that next generation search interfaces will be based on SPARQL or other RDF-stuff.

2. Availability: The announcement says: “This functionality will be implemented through a simple REST interface to be specified by the ILS-DI task group”. Yes, there is definitely a need (in december I wrote about such an API in German). However the main point is not the API but to define what “availability” means. Please focus on this. P.S: DAIA is now available.

3. Linking: For “Linking in a stable manner to any item in an OPAC in a way that allows services to be invoked on it” (announcement) there is no need to create new APIs. Add and propagate clean URIs for your items and point to your APIs via autodiscovery (HTML link element). That’s all. Really. To query and distribute general links for a given identifier, I created the SeeAlso API which is used more and more in our libraries.

Furthermore the draft contains a section on “Patron functionality” which is going to be based on NCIP and SIP2. Both are dead ends in my point of view. You should better look at projects outside the library world and try to define schemas/ontologies for patrons and patron data (hint: patrons are also called “customer” and “user”). Again: the API itself is not underdefined – it’s the data which we need to agree on.

Was ist eine URI?
Die Diskussion zum Thema URI/URN/URL auf Inetbib hat mal wieder gezeigt, dass es beim Thema Identifikatoren oft Missverständnisse gibt. Die international allgemeine Form globaler Identifikatoren ist der “Uniform Resource Identifier” (URI) bzw. die Erweiterung “Internationalized Resource Identifier” (IRI). Sie sind in RFC 3986 und RFC 3987 standardisiert. Die Vergabe von UR regelt RFC 4395. Verschiedene URI-Schemata (gekennzeichnet durch den Teil einer URI bis zum ersten Doppelpunkt) sind jeweils mit einem eigenen Standard registriert und definiert, zum Beispiel URNs durch RFC 2141.

Viele URI-Schemata legen Namensräume und eigene Regeln zur Struktur und Vergabe von Identifikatoren fest. So zum Beispiel RFC 3406 für URNs und RFC 3044 für den URN-Namensraum urn:issn zur Abbildung von ISSNs. Durch die Formulierung von ISSNs als URI können diese bereits etablierten aber nur begrenzt nutzbaren Identifikatoren auch global genutzt werden, beispielsweise im Rahmen des Semantic Web. Während die Zeichenfolge “0024-9319″ sehr unterschiedliches identifizieren kann, weist “urn:issn:0024-9319″ eindeutig auf die amerikanische Ausgabe des MAD-Magazins hin.

Um welche Identifikatoren geht es?
Zur Identifikation von Personen (PND), Begriffen (SWD) und Körperschaften (GKD) gibt es im deutschen Bibliothekssystem seit vielen Jahren etablierte Normdaten. Abgesehen von wenigen Ausnahmen fristen diese Normdaten bzw. ihre Identifikatoren jedoch eher ein Schattendasein. Andere Identifikatoren, wie beispielsweise die Nummern von OCLC und der Library of Congress werden dagegen auch zunehmend von den “global players” im Netz verwendet (von Google und LibrayThing). Wenn sie endlich mit URIs versehen und frei veröffentlicht würden, könnten die deutschen Normdateien ebenfalls weitere Verbreitung finden – oder andernfalls an Bedeutung verlieren.

Was hat die DNB falsch gemacht?
Anscheinend ist nun bei der Erstellung von Identifikatoren für Normdaten bei der Deutschen Nationalbibliothek gleich an mehreren Stellen etwas schief gelaufen. Dabei sieht es auf den ersten Blick ganz gut aus: Beim SWD-Eintrag “Poetry Slam” ist beispielsweise dort als “Id” die Zeichenkette “info://d-nb.de/965692973” angegeben:

Ist das eine URI? Nein. In der offiziellen Liste von URI-Schemata ist “info:” als gültiges URI-Schema eingetragen, das durch RFC 4452 definiert wird. Die dort festgelegte Maintenance Authority NISO hat die Verwaltung von Namensräumen an OCLC weitergegeben. Nun bekleckert sich OCLC mit dem seit Wochen nicht erreichbaren Verzeichnis der vergebenen Unternamensräume auch nicht gerade mit Ruhm, aber immerhin gibt es klare Standards (mehr Informationen bei der LOC). Eine info-URI ist aufgebaut nach dem Schema “info:NAMENSRAUM/LOKALTEIL“. Die Zeichenkette “info://d-nb.de/965692973″ kann also schon formal keine URI sein. Außerdem ist “d-nb.de” nicht als gültiger info-URI Namensraum registriert. Zu allem Überfluss wird nicht auf die etablierten SWD-Nummern zurückgegriffen (die SWD-Nummer für den SWD-Datensatz ist “4709615-9″), sondern als lokaler Bestandteil die nicht standardisierte, systemabhängige PND-Nummer (hier: 965692973) verwendet!

Wie lässt sich der Schlamassel beheben?
Leider ist dies nicht das erste mal, dass sich die DNB im Internet lächerlich macht. Zum Glück lassen sich die Fehler relativ einfach beheben.

1. Die bereits existierenden “Standards” für die existierenden Normdaten-Nummern werden explizit und verlässlich festgeschrieben, d.h. erlaubte Zeichen und Wertebereiche, Berechnung der Prüfziffer und Normalisierung (siehe LCCN-Normalisierung).

2. Die DNB reserviert für die Normdaten-Nummern einen URI-Namensraum (beispielsweise info:swd, info:pnd, info:gkd). Dabei sind die Regeln zur Syntax und Vergabe von URI-Schemata und Namensräumen einzuhalten. Internationale Standards sind zum Lesen und Einhalten da und nicht zum Ignorieren und Uminterpretieren.

3. Die URIs werden verständlich dokumentiert und propagiert. Die Kür wäre eine völlige Freigabe der Normdaten als öffentlicher Datenbank-Abzug unter einer freien Lizenz.

Zur Klärung der Konfusion bezüglich URI und URL sei auf die Artikel URIs, URLs, and URNs: Clarifications and Recommendations (via Kay Heiligenhaus) und On Linking Alternative Representations To Enable Discovery And Publishing hingewiesen.

P.S: Eine bibliotheksrelevante Anwendung von von Identifikatoren für Personen wurde letzte Woche von Arjan Hogenaar and Wilko Steinhoff im Vortrag Towards a Dutch Academic Information Domain auf der Open Repositories 2008 vorgestellt.

Gestern hat OpenMoko die CAD-Baupläne des Neo 1973 unter der CC BY-SA Lizenz freigegeben – neben der Software ist also auch das Gehäusedesign frei veränderbar. Die für den Massenmarkt geplante, überarbeitete “Neo FreeRunner” soll noch im “Frühjahr Frühsommer 2008″ verfügbar sein – ich schätze mal, dass heisst dann frühestens im August.

Search: SRU/SRW (including CQL), OpenSearch, Z39.50

Harvest/Syndicate: OAI-PMH, RSS, Atom Syndication (also with ATOM Extensions)

Copy/Provide: unAPI, COinS, Microformats (not a real API but a way to provide data)

Upload/Edit: SRU Update, Atom Publishing Protocol

Identity Management: Shibboleth (and other SAML-based protocols), OpenID (see also OSIS)

For more complex applications, additional (REST)-APIs and common metadata standards need to be found (or defined) – but only if the application is just another kind of search, harvest/syndicate, copy/provide, upload/edit, or Identity Management.

P.S: I forgot NCIP, a “standard for the exchange of circulation data”. Frankly I don’t fully understand the meaning and importance of “circulation data” and the standard looks more complex then needed. More on APIs for libraries can be found in WorldCat Developer Network, in the Jangle project and a DLF Working group on digital library APIs. For staying in the limited world if libraries, this may suffice, but on the web simplicity and availability of implementations matters – that’s why I am working on the SeeAlso linkserver protocol and now at a simple API to query availaibility information (more in August/September 2008).

P.P.S: A more detailed list of concrete library-related APIs was published by Roy Tennant based on a list by Owen Stephens.

P.P.S: And another list by Stephen Abram (SirsiDynix) from September 1st, 2009

Um sich nicht im Sommerloch langweilen zu müssen, habe ich hier eine kleine Aufgabe für ISBD-Experten, Bibliothekare und andere Zukunftsinteressierte: Es geht um nicht weniger als die die Entwicklung eines bibliothekarischen Datenformates. Da der Beitrag etwas länger ist, hier eine

Zusammenfassung

1. Im Web sind mehr und mehr Daten direkt und in standardisierten Formaten zur Weiterverarbeitung verfügbar
2. Durchsetzen wird sich am Ende das, was im Browser ohne Plugin unterstützt wird
3. So wie es aussieht, werden dies Mikroformate sein
4. Für Bibliographsche Daten fehlt bislang ein Mikroformat
5. Wenn sich Bibliothekare nicht mit ihrem Sachverstand an der Entwicklung eines solchen Formates beteiligen, tun es andere – und das nicht unbedingt nach bibliothekarischen Gesichtspunkten.

Worum geht es?

Im Rahmen des “Web 2.0″-Hypes tauchen immer wieder Begriffe wie “Web 3.0″ oder “Semantic Web” auf. Damit wird (abgesehen von der Verwendung als Buzzword) auf die folgende wichtige Entwicklung des Webs angespielt: Immer mehr Daten stehen direkt und in standardisierten Formaten zur Weiterverarbeitung zur Verfügung. Einfache Beispiele sind RSS und Dublin Core; auf der anderen Skala der Komplexität stehen Ontologien und RDF. Auch das Millionenprojekt Theseus hat zum Ziel, so genannte “semantische Technologien” zu entwickeln.

Ich gehe jede Wette ein, dass in Zukunft mehr und mehr Daten mittels “Semantischem Markup” in Webseiten integriert werden – bislang fehlte es jedoch an einer “Killerapplikation” und noch ist nicht festgelegt, in welcher Form die Daten in Webseiten eingebunden werden. Eine bereits jetzt nutzbare Form für bibliographische Daten ist das auf OpenURL basierende COinS (ContextObjects in Spans). Allgemeinere Formen für verschiedene Arten von Daten sind Microformats und RDFa (hier ein Vergleich der beiden und ein Beispiel auf Deutsch hier von Carsten Schulze).

Ob und wo sich Webstandards langfristig durchsetzen, hängt nicht zuletzt davon ab, ob sie standardmäßig von Webbrowsern unterstützt werden – bislang ist dies an über HTML hinausgehenden Formaten nur für RSS der Fall. Nun ist es so, dass die vorraussichtlich Ende 2007 erscheinende Version 3.0 des Firefox-Webbrowsers Microformats unterstützen wird. Und Microsoft ist dabei, die Zwischenablage so zu erweitern, dass einzelne Objekte von Webseiten kopiert werden können (auszuprobieren mit Live Clipboard)- die ersten Anwendungen sind die Mikroformate hCal und hCard. Damit ist klar, wohin die Entwicklung geht.

Was sind Mikroformate?

Mit Mikroformaten können Webseiten so durch Markup angereichert werden, dass ihre Inhalte möglichst detailliert auch für Computerprogramme verarbeitbar sind (dazu gibt es eine gute Einführung). Hier als Beispiel meine Dienstanschrift:

So kann es ein Mensch verstehen:

Verbundzentrale des GBV
Jakob Voß
Platz der Goettinger Sieben 1
37073 Göttingen
+49 (0)551 39-10242
jakob.voss@gbv.de

Und so muss es in HTML als vcard-Microformat angegeben sein, damit es auch Computer verstehen (erstellt mit dem Generator für hCard:

<div class="vcard">
 <div class="org">Verbundzentrale des GBV</div>
 <span class="fn">Jakob Voß</span>
 <div class="adr" class="work">
   <div class="street-address">Platz der Goettinger Sieben 1</div>
     <span class="postal-code">37073</span>
     <span class="locality">Göttingen</span>
 </div>
 <div class="tel">+49 (0)551 39-10242</div>
 <div class="email">
     <a href="mailto:jakob.voss@gbv.de"; class="email" >jakob.voss@gbv.de</a>
 </div>
</div>

Derzeit gibt es eine Reihe von etablierten Mikroformaten und weitere sind in Entwicklung. Die Dokumentation und Diskussion findet offen in einem Wiki statt. Eine Einführung in Mikroformate bietet auch das Buch “Microformats: Empowering Your Markup for Web 2.0″ und ein weiteres eBook auf deutsch.

Was hat das alles mit Bibliotheken zu tun?

Derzeit gibt es noch kein einheitliches Microformat für bibliographische Angaben – allerdings schon einige Ansätze. Es ist zwar alles andere als trivial, ein bibliographisches Datenformat zu entwickeln, aber das Web funktioniert pragmatisch – ich gehe davon aus, dass sich ein citation-Microformat durchsetzen wird, sobald jemand einen Standard dafür festlegt und umsetzt. Dabei kommt es nicht darauf an, wie gut dieser Standard ist, sondern dass er gut dokumentiert, verfügbar und benutzbar ist und dass er von einer kritischen Masse von Anbietern verwendet wird (siehe dazu VHS vs. Betamax und Video 2000).

Nun können wir als bibliothekarisches Fachpersonal a) entweder abwarten, bis sich der citation-Microformat-Standard stabilisiert hat und danach darüber wundern, dass er aus bibliothekarischer Sicht an der einen oder anderen Stelle völlig unzureichend ist oder b) uns aktiv an der Entwicklung des citation-Microformat-Standards beteiligen und ihre bibliothekarische Sachkompetenz einfließen lassen.

Und hier kommt ISBD ins Spiel!

Ich möchte zunächst betonen, dass die der Katalogisierung, Ansetzung und dem Aufbau von Titelanzeigen nicht mein Fachgebiet sind. Soweit ich das Konzept der International Standard Bibliographic Description (ISBD) verstanden habe, legt dieser Standard fest, wie eine Titelaufnahme im Katalog aussehen sollte – vereinfacht gesagt also die Reihenfolge und Trennzeichen von Autor, Titel, Verlag und all die anderen Datenfelder einer Titelaufnahme. Obgleich viele Kataloge sich nicht streng an ISBD halten ist das Prinzip das gleiche: irgendwo ist festgelegt, welche Titeldaten in welcher Weise formatiert angezeigt werden.

Bei Mikroformaten ist es ganz ähnlich. Nur wird bei einem Mikroformat statt mit Sonderzeichen wie ; – [..] und , mit HTML-Tags <div> <span> und dem class-Attribut strukturiert.

Die Aufgabe besteht, wie schon von anderer Seite angedeuted also darin, eine Abbildung von ISBD (bzw. der am häufigsten in OPAC-Titelanzeigen verwendeten Untermenge) auf ein Mikroformat zu finden. Hier mal ein naiver Ansatz anhand eines konkreten Beispiels der folgenden Titelaufnahme (übrigens Herzlichen Glückwunsch an die Braunschweiger, die als erste GBV-Verbundbibliothek den neuen Harry Potter im Bestand haben

Titel: Harry Potter and the deathly hallows / Joanne K. Rowling. – [Children's ed.], 1. ed. – London : Bloomsbury, 2007
ISBN: 0-7475-9105-9 – 978-0-7475-9105-4 (Children’s edition)

Die bedeutungstragenden Bestandteile werden nun hierarchisch ausgezeichnet, ohne den Text selber zu verändern (das geht auch gut mit Papier und verschiedenfarbigen Stiften):

<div class='hCitation'>
  Titel:
  <span class='title'>Harry Potter and the deathly hallows</span> /
  <span class='n'>
    </span><span class='given-name'>Joanne K.</span>
    <span class='family-name'>Rowling</span>
  </div>. -
  [<span class='edition'>Children's ed.</span>], <span class='edition-number'>1.</span> ed. -
  <span class='location'>London</span> : <span class='publisher-name'>Bloomsbury</span>,
  <span class='publication-year'>2007</span>
</div>
<div>
  ISBN:
  <span class='ISBN'>0-7475-9105-9</span> -
  <span class='ISBN'>978-0-7475-9105-4</span>
  (<span class='edition'>Children's edition</span>)
</div>

Dabei muss festgelegt werden, wie fein die Daten aufgespalten werden sollen und wie die einzelnen Elemente mit class=”…” benannt werden. Sicherlich können nicht alle in ISBD vorhandenen Spezialfelder und Sonderregeln berücksichtigt werden, die Anzahl der Felder soll schließlich überschaubar bleiben. Aüßerdem müssen wo möglich, bereits bestehende Microformats und andere Formate berücksichtigt werden – so sind die Feldbezeichnungen für Namen mit ‘n’, ‘given-name’ und
‘familiy-name’ bereits im hCard-Standard festgelegt, da gibt es also nichts zu ändern.

Was also zu erstellen ist, ist eine genaue Festlegung eines Mikroformats für bibliographische Angaben. Vielleicht kann auch von anderen Standards als ISBD ausgegangen werden (OpenURL, RAK, AACR, MAB, MARC, MODS, BibTeX…) – in jedem Fall muss aber die Titelanzeige ausgezeichnet werden, so wie sie der Nutzer im Katalog sieht. Um es nochmal zu betonen: Wenn Firefox und Microsoft sich auf Mikroformate festlegen und diese von Haus aus unterstützen, ist es völlig egal, wie gut Mikroformate sind und ob es Alternativen gibt.

Der traditionelle Weg wäre vermutlich, eine Arbeitsgruppe “Mikroformate” mit den entsprechenden Experten einzurichten. Das kann
zwar grundsätzlich nicht schaden, jedoch sollte folgendes bedacht werden: Erstens hätte diese AG sowieso keinerlei Entscheidungsbefugnisse, da die Diskussion offen im Microformate-Wiki stattfindet, wo sich jeder beteiligen kann und zweitens haben wir keine Zeit für langwierige Projektplanungsphasen. Was zählt ist nur das direkt online verfügbare Ergebnis und kein Projektbericht oder Sitzungsprotokoll. Siehe dazu dieses schöne Posting, das den Konflikt von Bibliothekaren mit solch pragmatischen Lösungen darlegt.

Das das Format am Ende allen erdenklichen bibliothekarischen Ansprüchen genügen wird, bezweifle ich, aber es besteht zumindest die Möglichkeit, Einfluss zu nehmen und den bibliothekarischen Sachverstand einfliessen zu lassen – noch.

Wie kommen nun bibliothekarisches Know-How und Mikroformate zusammen?

Zunächst einmal sollte man sich etwas mit Mikroformaten vertraut machen – dazu gibt es die genannten Bücher und verschiedene Einführungen im Netz. Danach sind ISBD oder die Regeln zur Erzeugung der Titelanzeige im eigenen Katalog vorzunehmen und die atomaren bedeutungstragenden Bestandteile herauszuarbeiten. Diese sollten danach übersichtlich im Microformats-Wiki dargestellt und dort an konkreten Beispielen ausdiskutiert werden.

Die Nationalbibliothek von Australien (NLA) hat vor einiger Zeit einen sehr ansehnlichen Lucene-basierten Katalog-Prototypen veröffentlicht. Dass die NLA zukunftsweisende Entwicklungen betreibt, zeigt auch die geospatial search (deren Eingabemaske allerdings nicht sehr komfortabel ist) und den im März diesen Jahres veröffentlichten National Library of Australia IT Architecture Project Report auf den ich hiermit hinweisen möchte. Den folgenden Absatz aus dem Report könnte ich direkt unterschreiben:

The benefits of having a native level of support for standard protocols in the architecture cannot be overestimated. A standards-based service-oriented approach for core services such as Contribute, Alert, Harvest and Request will allow protocols such as SRU Update, RSS, OAI-PMH and OpenURL to be supported across all applications. It will also ensure that these protocols are part of the Library’s way of thinking when training new staff or prototyping new requirements; and that gaps in standards are identified and addressed through a testbed approach, as part of the development process.

Übrigens setzt die NLA wie der GBV auch als Zentralsystem das CBS von OCLC PICA ein.

I am currently browsing through the draft of British Standard BS 8723: Structured vocabularies for information retrieval, part 3 (Vocabularies other than thesauri) and 4 (Interoperability between vocabularies). I must confess that reading standards is mostly a pain, especially this old-fashioned pre-web standards in information retrieval. I tried to find out the ancestors of BS 8723 but it took me almost hours. There are dozen of poorly documented related standards and versions (BS 5723, BS 6723, ISO 2788, ISO 5964, DIN 1463, ANSI/NISO Z39.19, AFNOR Z 47 etc.) and most of them are not freely available (and the only available standards are paper-centered PDF instead of web-centered HTML/XML). A standard that is not accesible is pretty worthless! I often complain about the Semantic Web community that ignores most of traditional information retrieval – but they understandably ignore previous results: If traditional information retrieval has not even achieved to visibly and clearly document its own standards on the web – what is it worth for? A general overhaul is necessary: SKOS and collaborative tagging are only two representatives of this change. I fear that BS 8723 will not be part of the new times unless it becomes available Hypertext.