Querying Freebase to Find Public Domain Authors

In October I wrote about querying DBpedia to find out which authors were born in 1942 resulting in their works (probably) entering the public domain in 2013. In a comment on this post, Tom Morris pointed out that a simple Freebase query easily leads to more results than the - ever-increasing - SPARQL query I had provided for DBpedia (Thanks, Tom). Eventually, I used Freebase to get a list of public domain authors as querying DBpedia to this end turned out to be impractical. (Maybe, in the future libraries will provide data and tools to learn about works entering the public domain...)

Missing class hierarchy in DBpedia

Why is querying DBpedia impractical? Following my blog post, Jindřich Mynarz helped me to improve the SPARQL query on this etherpad. We soon realized that you'd have to build a UNION query with hundreds of classes in order to get all people who died in 1942 and who have published something during their lifetime. The reason is, that little class hierarchy in DBpedia exists. There seems to be some hierarchy in the YAGO ontology that we would have liked to exploit but unfortunately typos in the ontology (rdfs:suBClassOf, see e.g. http://dbpedia.org/class/yago/Essayist110064405) render this impossible.

Querying Freebase

As already mentioned, I ended up querying Freebase. I modified the query provided by Tom and finally got a list of 481 authors who died in 1942 as well as information about their concrete death date, their profession, nationality and works published. I did this using rather a trial and error approach than understanding the details of MQL (Metaweb Query Language). It resulted in this query:
    "type": "/book/author",
    "name": [],
    "/people/deceased_person/date_of_death": null,
    "mid": null,
    "/people/person/nationality" : [],
    "/people/person/profession" : [],
    "works_written": [],
    "d2:/people/deceased_person/date_of_death<": "1942-12-31",
    "/people/deceased_person/date_of_death>": "1941-12-31",
    "limit": 500
Unfortunately, a query like this with a limit of 500 results would time out. It took me some time to search through the documentations and to finally find out how to employ the cursor in a Freebase query to handle off-sets. At last I came up with this query (now as URL) which worked fine for my purpose:


Conversion to Spreadsheet with Google Refine

At last, I needed to convert the JSON files Freebase was providing into CSV or similar to be able to upload it to a Google Spreadsheet. I used Google Refine (in transition to Open Refine), a tool that I have been wanting to try out for quite some time now. It was a logical step to use this tool for my purposes anyhow as it originates from the same people who have developed Freebase...
Google Refine was easy to install. It was also easy to upload the JSON to do some adjustments (mainly moving and renaming columns) and then I could directly upload the result to this Google spreadsheet.


I hope, the list of authors and possible public domain works may be useful to some people. It assumes that works enter the public domain 70 years after the author's death which is true for most countries. Of course, this list has to be taken with some care, so you might want to clarify the individual case before digitizing the works and publishing them on the internet. The list also includes many translations of original works which will probalby not enter the public domain in 2013 as translators usually enjoy a copyright for their translations. IANAL.


Querying DBpedia to find Public Domain Authors

Yesterday, Sam Leon asked for help to populate a list of authors whose work will enter the public domain in 2013. My first thought was: This is a perfect use case for querying DBpedia's SPARQL endpoint! So I tried some queries.

Unfortunately, I had problems with the xsd datatypes when I built my query on the properties dbpedia-owl:deathYear and/or dbpedia-owl:deathDate. Doing a quick search on the web, I noticed that problems with xsd:date aren't new to DBpedia. It didn't work out to write a query guided by the workarounds provided in [1] and [2]. Perhaps somebody else can tell me, how you can solve these problems...

I decided to query based on the wikipeda category 1942 deaths. With this kind of query i had no problems, for example:

PREFIX dbpedia-owl: <http://dbpedia.org/ontology/>
PREFIX dct: <http://purl.org/dc/terms/>

SELECT ?person {
    ?person a dbpedia-owl:Writer .
    ?person dct:subject <http://dbpedia.org/resource/Category:1942_deaths> .
(See the result for the previous query here.)

This query only delivers persons that are typed as dbpedia-owl:Writer. Franz Boas for example isn't covered. One would have to do more queries with other categories of people that publish written works:
One can combine queries of multiple classes in SPARQL with a UNION query. To only list those people once that are members of multiple classes, one should add a DISTINCT to the SELECT query, for example:
PREFIX dbpedia-owl: <http://dbpedia.org/ontology/>
PREFIX dct: <http://purl.org/dc/terms/>

    { ?person a dbpedia-owl:Scientist }
    { ?person a dbpedia-owl:Writer }
    { ?person a dbpedia-owl:Philosopher }
    { ?person a <http://dbpedia.org/class/yago/AmericanAnthropologists> }
    { ?person dct:subject <http://dbpedia.org/resource/Category:German_poets>  }
    ?person dct:subject <http://dbpedia.org/resource/Category:1942_deaths> . 

Note, that you can also use relevant categories connected to the person by dcterms:subject. This SPARQL query already delivers 102 persons who died in 1942 and most probably all have published at least one written work. The query needs to be extended to cover most of the people in Wikipedia/DBpedia that have published written works.

As one can see, these queries aren't as simple as you would like them to be. That's because you have to adjust to the underlying data which - like all data on the web - is kind of messy. The good thing is: If you have worked out a useful SPARQL query that includes most of the categories and subject classes for people who publish stuff, you can easily re-use the query for upcoming lists of public domain material in coming years.

[1] http://answers.semanticweb.com/questions/947/dbpedia-sparql-endpoint-xsddate-comparison-weirdness

[2] http://pablomendes.wordpress.com/2011/05/19/sparql-xsddate-weirdness/


Ob Jakob log oder die Zukunft voraussah?

Jakob Voß hat vor gut fünf Jahren nach dem Start der Open Library folgendes prophezeit:
"In spätestens 5 Jahren werden alle wesentlichen Katalogdaten frei sein, zu einem wesentlichen Teil nicht mehr ausschließlich von Bibliothekaren erstellt werden und verschiedene Anbieter werden Suchfunktionen über diese Daten bereitstellen. Auf diesen Wandel sollte sich das Bibliothekswesen einstellen."
Nicht schlecht, Jakob. Ich würde sagen, die Prognose war ziemlich gut. Fünf Jahre nach dem Beitrag sind etliche Normdaten offen zugänglich (viaf.org, DNB u. a.) sowie Titeldaten verschiedenster Organisationen (DNB, BNB, Spanische NationalbibliothekHarvard LibraryEuropeana, hbz, BVB und bei WorldCat/OCLC ist es ja auch losgegangen).[1] Ob das schon "alle wesentlichen Katalogdaten" sind, da kann man vielleicht drüber streiten...

Interessant ist der zweite Teil der Prognose, dass die Katalogdaten 2012 "zu einem wesentlichen Teil nicht mehr ausschließlich von Bibliothekaren erstellt" würden. Dies hat sich bisher so nicht bewahrheitet. Was die offen im Web publizierten Katalogdaten angeht, befinden sich die in bibliothekarischen Institutionen erstellten Daten - wenn ich das richtig einschätze - derzeit klar in der Überzahl. (Ausschließlich wurden Katalogdaten ja ohnehin nie von Bibliothekaren erstellt, wenn man etwa Verlagsdaten dazuzählt.)

Ich denke, die Bibliothekswelt hat sich sehr gut eingestellt auf die sich mit dem Start der Open Library 2007 abzeichnende Entwicklung zu offenen Katalogdaten : Seit 2010 wächst die Zahl der Projekte, in denen Katalogdaten befreit werden. Deshalb ist heute die Open Library nur ein Datenpool unter vielen und ein großer Teil der freien Katalogdaten im Web ist bibliothekarischen Ursprungs. Dazu kommen mittlerweile noch offene bibliographische Daten von Verlagen wie etwa von der Nature Publishing Group. Und sicher wird auch Wikidata in Zukunft einiges zu diesen "Bibliographic Commons" beitragen bzw. daraus schöpfen.

Die wechselseitige Verlinkung, Nachnutzung und Anreicherung der durch Bibliothekare erstellten Daten, der Daten von Verlagen, der Open Library, Wikidata und ähnlichen Diensten steht allerdings noch aus. Dies ist der nächste wichtige Schritt nach der Freigabe der Daten. Zu diesem Zweck gilt es unter anderem, Antworten auf die Fragen nach Provenienzinformationen und Datensynchronisierung zu entwickeln. Beides sind Dinge, an denen schon verschiedentlich gearbeitet wird (z.B. in der Provenance Working Group beim W3C und in ResourceSync-Initiative von NISO und OAI) und die übrigens auch bei der diesjährigen SWIB Thema sein werden.

[1] Für eine Übersicht über frei nachnutzbare bibliographische Daten siehe http://thedatahub.org/group/bibliographic.


Linked Data in worldcat.org

Two days ago OCLC announced that linked data has been added to worldcat.org. I took a quick look at it and just want to share some notes on this.

OCLC goes open, finally

I am very happy that OCLC - with using the ODC-BY license - finally managed to choose open licensing for WorldCat. Quite a change of attitude when you recall the attempt in 2008 to sneak in a restrictive viral copyright license as part of a WorldCat record policy (for more information see the code4lib wikipage on the policy change or my German article about it). Certainly, it were not at last the blogging librarians and library tech people, the open access/open data proponents etc. who didn't stop to push OCLC towards openness, who made this possible. Thank you all!

Of course, this is only the beginning. One thing is, that dumps of this WorldCat data aren't available yet (see follow-up addendum here), thus, making it necessary to crawl the whole WorldCat to get hold of the data. Another thing is, that there probably is a whole lot of useful information in WorldCat that isn't part of the linked data in worldcat.org yet .

schema.org in RDFa and microdata

What information is actually encoded as linked data in worldcat.org? And how did OCLC add RDF to worldcat.org? It used the schema.org vocabulary to add semantic markup to the HTML. This markup is both added as microdata - the native choice fo schema.org vocab - as well as in RDFa. schema.org lets people choose how to use the vocabulary, on the schema.org blog it recently said: "Our approach is "Microdata and more". As implementations and services begin to consume RDFa 1.1, publishers with an interest in mixing schema.org with additional vocabularies, or who are using tools like Drupal 7, may find RDFa well worth exploring."

Let's take a look at a description of a bibliographic resource in worldcat.org, e.g. http://www.worldcat.org/title/linked-data-evolving-the-web-into-a-global-data-space/oclc/704257552The part of the HTML source containing the semantic markup is marked as "Microdata Section" (although it does also contain RDFa). As the HTML source isn't really readable for humans, we need to get hold of the RDF in a readable form first to have a look at it. I prefer the turtle syntax for looking at RDF. One can get the RDF contained in the HTML out using the RDFa distiller provided by the W3C. More precisely you have to use the distiller that supports RDFa 1.1 as schema.org supports RDFa 1.1 and, thus, worldcat.org is enriched according to the RDFa 1.1 standard.

However, using the distiller on the example resource I can get back a turtle document that contains the following triples:

1:  @prefix library: <http://purl.org/library/> .  
2:  @prefix madsrdf: <http://www.loc.gov/mads/rdf/v1#> .  
3:  @prefix owl: <http://www.w3.org/2002/07/owl#> .  
4:  @prefix schema: <http://schema.org/> .  
5:  @prefix skos: <http://www.w3.org/2004/02/skos/core#> .  
6:  <http://www.worldcat.org/oclc/707877350> a schema:Book;  
7:    library:holdingsCount "1"@en;  
8:    library:oclcnum "707877350"@en;  
9:    library:placeOfPublication [ a schema:Place;  
10:        schema:name "San Rafael, Calif. (1537 Fourth Street, San Rafael, CA 94901 USA) :"@en ];  
11:    schema:about [ a skos:Concept;  
12:        schema:name "Web site development."@en;  
13:        madsrdf:isIdentifiedByAuthority <http://id.loc.gov/authorities/subjects/sh98004795> ],  
14:      [ a skos:Concept;  
15:        schema:name "Semantic Web."@en;  
16:        madsrdf:isIdentifiedByAuthority <http://id.loc.gov/authorities/subjects/sh2002000569> ],  
17:      <http://dewey.info/class/025/e22/>,  
18:      <http://id.worldcat.org/fast/1112076>,  
19:      <http://id.worldcat.org/fast/1173243>;  
20:    schema:author <http://viaf.org/viaf/38278185>;  
21:    schema:bookFormat schema:EBook;  
22:    schema:contributor <http://viaf.org/viaf/171087834>;  
23:    schema:copyrightYear "2011"@en;  
24:    schema:description "1. Introduction -- The data deluge -- The rationale for linked data -- Structure enables sophisticated processing -- Hyperlinks connect distributed data -- From data islands to a global data space -- Introducing Big Lynx productions --"@en,  
25:      "The World Wide Web has enabled the creation of a global information space comprising linked documents. As the Web becomes ever more enmeshed with our daily lives, there is a growing desire for direct access to raw data not currently available on the Web or bound up in hypertext documents. Linked Data provides a publishing paradigm in which not only documents, but also data, can be a first class citizen of the Web, thereby enabling the extension of the Web with a global data space based on open standards - the Web of Data. In this Synthesis lecture we provide readers with a detailed technical introduction to Linked Data. We begin by outlining the basic principles of Linked Data, including coverage of relevant aspects of Web architecture. The remainder of the text is based around two main themes - the publication and consumption of Linked Data. Drawing on a practical Linked Data scenario, we provide guidance and best practices on: architectural approaches to publishing Linked Data; choosing URIs and vocabularies to identify and describe resources; deciding what data to return in a description of a resource on the Web; methods and frameworks for automated linking of data sets; and testing and debugging approaches for Linked Data deployments. We give an overview of existing Linked Data applications and then examine the architectures that are used to consume Linked Data from the Web, alongside existing tools and frameworks that enable these. Readers can expect to gain a rich technical understanding of Linked Data fundamentals, as the basis for application development, research or further study."@en;  
26:    schema:inLanguage "en"@en;  
27:    schema:isbn "1608454312"@en,  
28:      "9781608454310"@en;  
29:    schema:name "Linked data evolving the web into a global data space"@en;  
30:    schema:publisher [ a schema:Organization;  
31:        schema:name "Morgan & Claypool"@en ];  
32:    owl:sameAs <http://dx.doi.org/10.2200/S00334ED1V01Y201102WBE001> .  

This looks quite nice to me. You see, how schema.org let's you easily convey the most relevant information and the property names are well-chosen to make it easy for humans to read the RDF (in contrast e.g. to the ISBD vocabulary which uses numbers in the property URIs following the library tradition :-/).

The example also shows the current shortcomings of schema.org and where the library community might put some effort in to extending it, as OCLC has already been doing for this release with the experimental "library" extension vocabulary for use with Schema.org. E.g., there are no seperate schema.org properties for a table of content and an abstract so that they are both put into one string using ther schema:description property.

Links to other linked data sources

There are links to several other data sources: LoC authorities (lines 13, 16, 41, 44) , dewey.info (17), the linked data FAST headings (18,19), viaf.org (20,22) and an owl:sameAs link to the HTTP-DOI identifier (32). As most of these services are already run by OCLC and as the connections probably all were already existent in the data, creating these links wasn't hard work, which of course doesn't make them less useful.

Copyright information

What I found very interesting is the schema:copyrightYear property used in some descriptions in worldcat.org. I don't know how much resources are covered with the indication of a copyright year and how accurate the data is, but this seems a useful source to me for projects like publicdomainworks.net.

Missing URIs

As with other preceding publications of linked bibliographic data there are some URIs missing for things we might want to link to instead of only serving the name string of the respecting entity: I am talking about places and publishers. Until now, AFAIK URIs for publishers don't exist, hopefully someone (OCLC perhaps?) is already working on a LOD registry for publishers. For places, we have geonames but it is not that trivial to generate the right links. It's not a great surprise that a lot of work has to be done to build the global data space.


DAIA & describing organizations, services, collections in RDF

In January Jakob Voß published the request for comments for the final DAIA specification. DAIA - Jakob writes -
"is more than an implementation: it provides both, an abstract standard and bindings to several data languages (XML, JSON, and RDF). The conceptual DAIA data model defines some basic concepts and relationships (document, items, organisations, locations, services, availabilities, limitations…) independent from whether they are expressed in XML elements, attributes, RDF properties, classes, or any other data structuring method."
As I have put some thought into the RDF-description of libraries, their services, collections, locations etc. for my master thesis (PDF, German) and as I will be holding a talk on this topic - together with Jakob - at this year's Bibliothekartag, I finally submit this comment on DAIA.

DAIA - Why and how?

Why was DAIA developed in the first place? As Jakob describes it in a post from 2009 DAIA tries to provide an API specification that's missing in the standard APIs for libraries, an
"open, usable standard way just to query whether a copy of given publication – for instance book – is available in a library, in which department, whether you can loan it or only use it in the library, whether you can directly get it online, or how long it will probably take until it is available again."
Thus, the" Document Availability Information API (DAIA) defines a data model with serializations in JSON, XML, and RDF to encode and query information about the current availability of documents" (from the English introduction). That is a very important standard and I hope DAIA will become widely adopted by libraries and system providers. I hope that my comments may help improving DAIA.

The Data Model

Here, I will focus on the underlying conceptual DAIA data model and on the corresponding OWL ontology. I am neither a heavy API user nor an API engineer and as such simply have no expertise on this so that I won't comment on the API specification at all.

As seen in the graphical representation of the conceptual model, DAIA's core classes are "Document", "Organization", "Service" and "Item".

I won't go into all the details here, just take a look at the specification and the ontology.

In my master thesis I took quite another approach than Jakob as my thoughts originated from the problem how to add structured data - e.g. in form of RDFa - to existing library websites.  Naturally, I didn't focus on the availability of documents, in fact I didn't go deeper into this topic but put my thoughts into describing an organisation, its site(s), collection(s) and services. I had a look at some library websites to find out what kind of information normally is displayed there and how to classify it. My general conceptual model that served as basis for a more detailled study (update and slightly reduced for this purpose as well as leaving aside the serials problem)  looks like this:

The DAIA model and my approach look quite similar in that both data models contain the core classes Document, Service, Organisation and Item. But also these models differ in at least one point: While DAIA establishes a Storage class the latter model uses the two classes of Site and Collection to express similar information.

Questions, Comments and Suggestions

After having highlighted my background, I want to proceed with actually responding to Jakob's call with some comments. I already gave some input on the W3C-LLD mailing list and might repeat myself here.


I have a problem understanding why the Storage class exists at all and whether it makes sense. If a collection is stored in closed stacks, it's of no interest to the user where an item actually resides, what's important to her, is where to get it, i.e. to know where the circulation desk is. Thus, I think one could even decrease complexity by omitting the Storage class. All users and applications care about is where to obtain an item not where it actually comes from. Thus, it's services that really count, not storage. (If an item is stored in a reading room, I would go on and classify the reading room as a service where items can be viewed locally but cannot be lent.)


Every library curates at least one collection which might comprise a number of subcollections. Often, on their web sites libraries give information about their collections by indicating the number of items in them, their mode of access, acquisition policy, contact information for a sub collection as well as storage location etc. That's why it might be useful to also make use of a collection class and to describe collections. But collection description is definitely not necessary to provide good services for users to easily obtain material they already identified as relevant for their needs. It's useful for other cases in which a researcher wants to find a number of libraries holding special collections he might be interested in. Or for libraries to find similar institutions in order to share data for improving the acquisition of new material.

DAIA namespaces

I don't get it, why the DAIA service classes get their own namespace, adding a "Service/" to the DAIA namespace, e.g. for loan . This isn't common practice and is really annoying. When you are writing turtle you either have to declare an extra prefix for the Service namespace or you have to write the whole URI as slashes aren't allowed after a prefix. (At least rapper doesn't like it.)

Minor comments
  • An update of the graph model is needed as the dct:spatial property is displayed to link an Item to a Storage. That is neither mentioned anywhere in the ontology nor a correct use of this property.
  • To be able to have a more concrete discussion I provide an example RDF description in a seperate post.


Web-Thesauri im Wandel der Zeit

Im Anschluss an Joachim Neuberts gestrigen Vortrag im Rahmen des DINI-KIM-Workshops zum "Standard Thesaurus Wirtschaft (STW) als Dauerbaustelle" (Update: hier gibt es die Folien zu  Vortrag) war ein Hauptdiskussionspunkt die Frage, wie mit der Veränderung eines Thesaurus über die Zeit umzugehen sei.

Joachim nannte konkrete Zahlen, inwiefern sich der STW von einer Version zur anderen ändert: Neben einigen neuen Deskriptoren kommen etliche neue Nicht-Deskriptoren hinzu, Deskriptoren werden gelöscht oder erhalten neue präferierte Etiketten. All dies gilt es im Kontext einer Linked-Data-Variante des Thesaurus zu berücksichtigen und zu dokumentieren. Momentan gibt es im Linked-Data-STW einen übergeordneten URI für einen Deskriptor (z. B. http://zbw.eu/stw/descriptor/15441-2), die für alle seine Versionen steht. Bei Aufruf dieses URIs wird man mittels Redirect und Content Negotiation weitergeleitet auf die aktuelle Version der Deskriptorenneschreibung (http://zbw.eu/stw/versions/latest/descriptor/15441-2/about) im angefragten Format.

"Sammel"-URIs vs. Versionen-URIs

Diese Praxis eines Sammel-URIs, der für alle Versionen eine Deskriptors steht, wurde insbesondere von Georg Hohmann kritisiert. Ich habe sein Argument wie folgt verstanden: Sobald sich in unserer Beschreibung eines Konzepts auch nur ein wenig ändert, handelt es sich nicht mehr um die Beschreibung desselben Konzepts und muss einen neuen URI bekommen. Eine Änderung des präferierten Etiketts, die Ergänzung eines Nicht-Deskriptors oder die Ergänzung oder Löschung eines Verweises machen die Beschreibung also zu einer Beschreibung eines neuen Konzepts, was wiederum das Prägen eines neuen URIs nötig macht.

Übrigens: Ich finde es sehr problematisch, dass im Kontext von Thesauri und Klassifikationen häufig von "Konzepten"gesprochen wird (insbesondere SKOS ist mit diesem Sprachgebrauch durchwirkt). Das Denken in Konzepten verursacht m.E. mehr (Pseudo-)Probleme, wenn es um Dokumentationssprachen geht, als dass es Nutzen bringt. Aber dazu vielleicht mehr zu einem anderen Zeitpunkt. Im folgendenwerde ich jedenfalls konsequent von "Deskriptoren" sprechen.

Konsequente Umsetzung unmöglich

Ich gebe der Auffassung recht, dass sich Deskriptoren eine Thesaurus wandeln, sobald ihre Beschreibung verändert wird. Allerdings meine ich, dass ein Deskriptor auch durch andere Veränderungen einem stetigen Bedeutungswandel unterliegt. So wird die Bedeutung eines Deskriptors auch durch Löschung oder Hinzufügen anderer Deskriptoren desselben Thesaurus verändert, weil sich das Anwendungsgebiet des Deskriptors (seine Extension) dadurch erweitern oder verkleinern kann. Zudem ist ein Thesaurus kein in sich geschlossenes System. Vielmehr wird auch auf Deskriptoren von außen verwiesen, der Thesaurus verweist selbst auf Ausdrücke der natürlichen Sprache (mit Etiketten/Labels) und er wird von Katalogisieren und anderen bei der Inhaltserschließung angewandt. Dies führt dazu, dass die Bedeutung eines Deskriptors einem stetigen Wandel unterworfen ist.
  1. Ein Deskriptor besteht meist aus einer ID, einer Menge von (präferierten und alternativen) Etiketten, möglicherweise in verschiedenen Sprachen sowie aus einer Menge von Verweisen (broader, narrower, match, see also) auf andere Deskriptoren innerhalb oder außerhalb des eigenen Thesaurus. Seine Bedeutung wird primär durch diese Referenzen zur natürlichen Sprache und zu anderen Deskriptoren bestimmt. Folglich ändert sich diese Bedeutung auch, wenn sich an den Verweisen etwas ändert. So müsste also der URI eines Deskriptors jedes Mal angepasst werden, wenn sich bei einem Deskriptor etwas ändert, auf den jener verweist.
  2. Wie bereits erwähnt, wird ein Deskriptor allerdings nicht auschließlich oder hinreichend durch seinen Thesaurus-Eintrag definiert. Vielmehr bestimmt sekundär auch die Anwendung eines Deskriptors über dessen Bedeutung (Frei nach Wittgenstein: "Die Bedeutung eines Deskriptors ist sein Gebrauch in der Inhaltserschließung."). Es gibt sicher genügend Beispiele, wo ein Deskriptor im Widerspruch zu seiner ursprünglich intendierten Funktion benutzt wird, ich selbst habe dies schon häufig genug gesehen. Und wie wir von der natürlichen Sprache wissen, wird ein "falscher" Symbolgebrauch irgendwann korrekt, sobald genügend Menschen die "falsche" Verwendung praktizieren (Beispiele sind etwa "der Blog", "die URI", "wegen dem" etc.). Der Logik folgend, dass ein Deskriptor einen neuen URI braucht, sobald er nicht mehr "dasselbe Konzept" beschreibt, müsste sich mit jeder Anwendung eines Deskriptors seine URI ändern.
  3. Wie gesagt wird die Bedeutung eines Deskriptors innerhalb eines Thesaurus u.a. durch Verweis auf natürlichsprachige Etiketten definiert. Auch diese unterliegenden in ihrer Nutzung innerhalb einer Sprachgemeinschaft einem stetigen Wandel. Wenn gestern "Management" nur im Kontext der Führung von Unternehmen und anderen Organisationen benutzt wurde, haben sich heute die Verwendungskontexte erweitert. Müssten dies nicht die entsprechenden Einträge in Thesauri berücksichtigen und beim Gebrauchswandel eines Deskriptor-Labels den URI des Deskriptors verändern? Jeder Person dürfte klar sein, dass dies keinen Sinn ergibt.
URIs und Veränderung von Webressourcen in der Zeit

Ich bin zwar wie Georg Hohmann der Meinung, dass die in einem Thesaurus aufgereihten Deskriptoren einem ständigen Bedeutungswandel unterliegen:
  1. weil sich Deskriptoren wandeln, auf die ein Deskriptor verweist,
  2. weil sich die Verwendung des Deskriptors bei der Inhaltserschließung verändert,
  3. weil sich der Gebrauch der mit ihm assoziierten natürlichsprachlichen Etiketten wandelt
  4. und weil das Hinzufügen/Löschen neuer Deskriptoren zum Thesaurus das Anwendungsgebiet der anderen Deskriptoren beeinflusst
Diesen Wandel würde ich aber nicht unbedingt zum Anlass nehmen, bei jeder Bedeutungsänderung einen neuen URI zu prägen. Wie soll man aber sonst mit dem Problem umgehen?

Das hier diskutierte Problem wird im Web-Kontext durch die Unterscheidung von Ressource und Repräsentation zum Ausdruck gebracht. Ich habe etwa die Ressource, die durch den URI "http://www.spiegel.de/" identifiziert wird, von der ich allerdings zu verschiedenen Zeitpunkten verschiedene Repräsentationen, unter Umständen sogar in verschiedenen Sprachen oder Formaten (Language/Content Negotiation) ausgeliefert bekomme.

Es gibt also mindestens drei Dimensionen, in denen sich verschiedene Repräsentationen einer Web-Ressource voneinander unterscheiden können:
  • Format
  • Sprache
  • Zeitpunkt (und damit im Inhalt zu verschiedenen Zeitpunkten)
Der Logik folgend, dass unterschiedliche Dinge unterschiedliche URIs haben sollten, müsste jede Repräsentation ihre eigene URI bekommen. Dies wird aber derzeit nicht gemacht.

Es gibt derzeit Bemühungen, um den zeitlichen Aspekt einer Ressource zu berücksichtigen und die unterschiedlichen Repräsentationen adressierbar zu machen: Das Memento-Projekt möchte zur Content-Negotiation die zeitliche Dimension hinzufügen. So soll es möglich werden, bei der Anfrage einer Web-Ressource über den HTTP-Header eine bestimmte zeitliche Repräsentation dieser Ressource anzufordern.

Memento & Thesauri

Eine Memento-Implementierung in einem Online-Thesaurus würde es ermöglichen, Repräsentationen/Versionen eines Deskriptors zu einem bestimmten Zeitpunkt zu adressieren, ohne dass zusätzliche URIs für verschiedene Versionen geprägt werden müssten.

Eine solche Art der Versionierung auf Veröffentlichungsseite wäre allerdings nur eine Seite der Problemlösung. Auf Nutzungsseite, wenn es um die Verwendung von Deskriptioren in der Inhaltserschließung oder um Mappings zwischen Thesauri geht, wäre es genauso wichtig, den Zeitpunkt der Vergabe eines Deskriptors zu dokumentieren. Wie eine solche Dokumentation aussehen könnte, dazu hat sich Felix Ostrowski schon ein paar Gedanken gemacht. Ein anderer Ansatz wäre die Verwendung von dated URIs (DURIs), die in diesem Internet-Draft spezifiziert werden. DURIS würden es auch ermöglichen, über einzelne Versionen RDF-Statements zu verfassen.

Ich halte es für sinnvoll, einen generischen Ansatz zur Versionierung von Webressourcen einem Thesaurus-spezifischen Ansatz vorzuziehen und würde mich interessieren, was Thesaurus-Fachleute davon halten.


Beitrag zur Zukunft der BibCamps

Das Bib meets KnowledgeCamp 2012 ist vorbei und es war ein großer Erfolg. Ich freue mich sehr darüber und möchte allen an der Organisation Beteiligten meinen Dank ausdrücken: allen voran den FH-Studierenden, die einen Großteil der Planung, Organisation übernommen haben und eine optimale Infrastruktur für ein erfolgreiches BibCamp bereitgestellt und am Laufen gehalten haben. Ihren Dozenten Ursula Georgy und Tom Becker, die das Management übernommen haben. Den Mitorganisatoren Constanze Döring (Stadtbibliothek Köln), Elke Rösner und Ulrike Ostrzinski (ZB MED), Susanne Hilbring (Max-Planck-Institut für Gesellschaftsforschung, MPIfG) und natürlich Karlheinz Pape von der Gesellschaft für Wissensmanagement (gfwm).
Ich selbst war auch an der Organisation beteiligt und ich denke, wir alle können stolz auf das Ergebnis sein. Im Sinne einer gesunden Weiterentwicklung des BibCamps möchte ich im Weiteren auf einen Punkt eingehen, der zu einiger Diskussion während der Planungen geführt hat.

Man war nicht immer einig bei der Planung...

Sicher können sich alle Organisatoren darauf einigen, dass das #bkc12 ein großer Erfolg war. Bei der Planung des BibCamps fiel uns eine Einigung allerdings auch manchmal schwer, insbesondere als es um Sponsoren und ihre Außendarstellung im Rahmen des BibCamps ging. Da dieses Thema - soweit ich es mitbekommen habe - auch bei vorherigen BibCamps zu Diskussionen geführt hat, es aber nie öffentlich diskutiert wurde, möchte ich zu einer solchen Diskussion mit diesem Beitrag einladen. Auch denke ich, dass dieser Beitrag zukünftigen BibCamp-Organisatoren zur Vermeidung einiger Diskussionen nützlich sein kann.

Was das BibCamp ausmacht

Was gehört zu diesem "Geist des BibCamp"? Ich würde folgende Punkte zu den grundlegenden Dingen zählen:
  1. Die Teilnehmer/innen
  2. Räumlichkeiten
  3. Verpflegung
  4. WLAN
Dies sind sozusagen die notwendigen Bedingungen für ein erfolgreiches BibCamp. Sobald diese vier Dinge gegeben sind, ist der Erfolg eines BibCamps gesichert. Darüber sollten sich zukünftige Organisatoren im Klaren sein und nicht denken, sie müssten die von vorherigen BibCamps gesetzte Messlatte immer wieder erreichen oder gar überbieten. Nein, das müsst ihr nicht, sorgt erstmal dafür, dass die Fundamente stehen ehe ihr über Anbauten nachdenkt.

Sponsoren und Institutionen stehen im Hintergrund

Eine weitere Eigenschaft des BibCamps war es bisher, dass Organisationen - seien es Sponsoren oder veranstaltende Einrichtungen - immer im Hintergrund standen. Sie wurden auf dem Blog genannt und auch vielleicht bei der Begrüßung kurz erwähnt. Manche Sponsoren haben VertreterInnen zum BibCamp gesandt. In Hamburg wurden sogar die Räume nach den Sponsoren benannt. Logos, Banner, Stände oder eine anderweitige Präsenz von Organisatoren wie Sponsoren auf dem BibCamp selbst gab es aber nicht. Das war den Organisatoren bisher wichtig und es ist auch mir wichtig. Den Sponsoren ist dies auch klar und freundlicherweise finden sich immer wieder welche, die das BibCamp unterstützen. Danke.

Diese Unaufdringlichkeit der Sponsoren und kommerziellen Anbieter ist einer der Aspekte, in denen das BibCamp sich erfrischend von etablierten Veranstaltungen wie dem Bibliothekstag abhebt. Den Hauptorganisatoren von der FH Köln war dies bei der Planung des #bkc12 verständlicherweise nicht klar, hatten sie doch allesamt noch kein BibCamp besucht. Constanze, Elke und ich war es aber wichtig, den "Geist des BibCamps" zu bewahren, Logos, und Marken im Hintergrund zu halten und keine Banner oder werbenden Informationsstände auf einem BibCamp einzuführen.

Stand != Stand

Über Stände wurde unter den Organisatoren des #bkc12 besonders ausgiebig diskutiert. Hintergrund war, dass dem BIB in der anfänglichen Planungsphase untersagt wurde, einen Informationsstand im Rahmen des BibCamps aufzustellen, obwohl er einen solchen als eine Bedingung für eine 500-Euro-Spende nannte. In dieser Frage hatten sich insbesondere Constanze Döring, Elke Rösner und ich durchgesetzt, denn uns hatte gerade dieser Aspekt auf vorhergehenden BibCamps immer sehr gefallen. Informationsstände kann man sich ja schließlich auf allen anderen bibliothekarischen Konferenzen anschauen. Auf der anderen Seite waren wir aber auch kompromissbereit und es wurden zwei Stände erlaubt (die Cocktailbar der Firma Lenk und die Itinerant Poetry Library), weil sie eben keinen werbenden Charakter haben, sondern einen anderen Sinn verfolgten: Erfrischung respektive Unterhaltung/Wissensvermittlung. Ich denke, wir haben hier die richtige Wahl getroffen und werde mich auch weiterhin prinzipiell gegen werbende Informationsstände auf BibCamps aussprechen, seien diese von kommerziellen oder nicht-kommerziellen Organisationen.

Nicht nachvollziehen konnte ich die Reaktion des BIB, der sich ob der Absage des Standes not amused zeigte. Er ließ über Tom Becker als seinen Vertreter unter den BibCamp-Organisatoren verlauten, dass er in Zukunft seine finanzielle Unterstützung für BibCamps einstellen werde, weil er als "kommerzieller anbieter" hingestellt worden sei. Eine solche Typisierung des BIB als kommerzielle Entität lag allerdings allen Beteiligten fern, es haben sich lediglich einige gegen einen Infostand des BIB ausgesprochen. Meines Erachtens keine souveräne Reaktion des Berufsverbands.

Was meint ihr?

Mich würde interessieren, wie andere BibCamp-Teilnehmer/innen die Frage nach Ständen und generell der Sponsorenpräsenz auf dem BibCamp sehen. Hat euch die Zurückhaltung der Sponsoren bisher auch so sehr gefallen oder stündet ihr einer "Bibliothekstagisierung" (die ja auf anderen Ebenen ohnehin stattfindet, weil das BibCamp eben im Mainstream angekommen ist) des BibCamps, d.h. einer Zunahme von Werbeständen, Bannern etc. gleichgültig bis positiv gegenüber?