Bestandsnachweise mit einem CIDOC CRM-Application Profile

Auf meinen Beitrag Bestandsnachweise von Bibliotheken als Linked Data gab es einige Anmerkungen. Neben einigen Retweets wurde insbesondere die Komplexität des CRM angesprochen. Beispielhaft greife ich hier eine Reaktion von Karen Coyle (@karencoyle) in der Mailing-Liste der Schema Bib Extend Community Group heraus1: „[…] Although a friend and I were joking the other day that FRBRoo diagrams look frighteningly like a London Tube Map. […]“.

Auch in vielen Gesprächen am Rande der SWIB13 zeigt sich, dass die Akzeptanz für die CIDOC CRM-Welt an der vermeintlichen Komplexität des Modells scheitert. Auf der SWIB13 zeigte sich aber auch, dass an einigen Stellen neue Ontologien entstehen, deren Inhalte auch schon im CIDOC CRM abgebildet sind.2

Sicherlich sieht der Ansatz im CIDOC CRM recht komplex aus. Doch was bleibt letztlich davon übrig, wenn beispielsweise für eine wissenschaftliche Bibliothek die zugehörige Universität bzw. die Bibliothek selbst die administrativen Informationen der Einrichtung als Linked Open Data bereitstellt?

Meine bisherigen Betrachtungen zeigen die Mächtigkeit des Modells und die Zusammenhänge für bibliographische Informationen eher abstrakt. Ich werde mich daher nun mit der Frage auseinandersetzen, ob auf Basis des CIDOC CRM ein „Application Profile“ definierbar ist, welches tatsächlich anwendbar ist. Im Sinne der Unterscheidung zwischen Referenz- und Anwednungsontologie3 sollte es möglich sein, ein „Application Profile“ auf Basis des CRM zu definieren, welches im Retrieval durch das CIDOC CRM als Referenzontologie nutzbar wird.

Im folgenden entwickelt sich eine Beschreibung der Bestandsnachweise, bei der die Komplexität des auf dem CIDOC CRM basierenden Modells durch eine „Aufgabenteilung“ deutlich abnimmt.

„Man-Made Features“ und „Sites“
Wie im Beitrag über die Bestandsnachweise beschrieben, lässt sich mittels der CRM-Entität E27_Site4, E26_Physical_Feature5 und E25_Man-Made_Feature6 eine beliebige Örtlichkeit beschreiben.
Die folgenden Beispiele zeigen einige Datensätze für die TU Dortmund.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ecrm: <http://erlangen-crm.org/120111/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix org: <http://www.w3.org/ns/org#>
@prefix lgd: <http://linkedgeodata.org/page/triplify/> .
@prefix osm: <http://www.openstreetmap.org/> .
@prefix data: <http://data.ub.tu-dortmund.de/resource/> .

data:site/TUDortmundUniversity 
  a ecrm:E27_Site , org:Site ;
  skos:prefLabel "Technische Universität Dortmund"@de , "TU Dortmund University"@en ;
  skos:altLabel "TU Dortmund" , "Universität Dortmund"@de , "Dortmund University"@en ;
  rdfs:isDefinedBy data:site/TUDortmundUniversity/about.rdf ;
  ecrm:P46i_forms_part_of lgd:relation1829065 ;
  ecrm:P46_is_composed_of data:site/NorthernCampus , data:site/SouthernCampus ;
  org:siteOf data:gnd/16039348-6 .
data:site/NorthernCampus 
  a ecrm:E27_Site, org:Site ;
  skos:prefLabel "Campus Nord"@de , "Northern Campus"@en ;
  rdfs:isDefinedBy data:site/NorthernCampus/about.rdf ;
  ecrm:P46i_forms_part_of data:site/TUDortmundUniversity ;
  ecrm:P46_is_composed_of data:feature/VP_76 , ... , data:feature/EF_50 ;
  owl:sameAs lgd:way130972690 ;
  rdfs:seeAlso osm:way/130972690 .
data:feature/VP_76
  a ecrm:E25_Man-Made_Feature, org:Site ;
  skos:prefLabel "Vogelpothsweg 76" ;
  skos:altLabel "Zentralbibliothek"@de , "Central Library"@en , "ZB"@de , "CL"@en , "VP 76" ;
  rdfs:isDefinedBy data:feature/VP_76/about.rdf ;
  ecrm:P46i_forms_part_of data:site/NorthernCampus ;
  ecrm:P46_is_composed_of data:feature/VP_76/ThirdFloor , ... , data:feature/VP_76/BasementLevel2 ;
  owl:sameAs lgd:way17059611 ;
  rdfs:seeAlso osm:way/17059611 . 
  org:siteOf data:organisation/DE-290 , data:organisation/DE-290/GB1 , ... .

Um präzise Lagerangaben bei Bestandsnachweisen zu beschreiben, sind weitere Kenntnisse innerhalb von Gebäuden, z.B. über Abschnitte oder Etagen, notwendig. Diese lassen sich mittels CRM als E25_Man-Made_Feature beschreiben. Die folgenden Beispiele zeigen das dritte Obergeschoss, das zweite Untergeschoss sowie den Zeitschriftenlesesaal im Erdgeschoss des Gebäudes Vogelpothsweg 76 (VP_76) auf Campus Nord.

data:feature/VP_76/ThirdFloor
  a ecrm:E25_Man-Made_Feature , org:Site ;
  skos:prefLabel "3. Obergeschoss"@de , "Third Floor"@en ;
  skos:altLabel "3.OG"@de ;
  rdfs:isDefinedBy data:feature/VP_76/ThirdFloor/about.rdf ;
  ecrm:P46i_forms_part_of data:feature/VP_76 ;
  ecrm:P46_is_composed_of data:collection/290/0/Sn .
data:feature/JournalsReadingRoom
  a ecrm:E25_Man-Made_Feature , org:Site ;
  skos:prefLabel "Zeitschriftenlesesaal"@de , "Journals Reading Room"@en ;
  ecrm:P46i_forms_part_of data:feature/VP_76/GroundFloor .
]  .

Damit auch Aussagen in Bezug auf eine der dem Ort zugeordneten Organisation getroffen werden können, sind die Objekte auch vom Typ Site der W3C Organization Ontology.

Sammlungen in der Bibliothek
Die physischen Bestände sind in Bibliotheken in der Regel systematisch in Sammlungsbereiche geordnet, z.B. als Sektionen basierend auf einer Systematik wie die Dewey Decimal Classification (DDC). Der Charakter dieser Sammlungen findet sich in der CRM-Entität E78_Collection wieder und kann mittels der Eigenschaft „forms part of“ einem „Feature“ und mittels „has current or former curator“ einer Einrichtung zugeordnet werden.
Die folgenden Code-Beispiele zeigen einerseits die Signaturgruppe Sn, welche in der „Freihand“-Sammlung verortet ist und andererseits die „Lehrbuchsammlung“. Beide sind Teil der gesamten Sammlung der Zentralbibliothek.

data:collection/290/0
  a ecrm:E78_Collection ;
  skos:prefLabel "Central Library"@en , "Zentralbibliothek"@de ;
  skos:altLabel "ZB"@de , "CL"@de ;
  rdfs:isDefinedBy data:collection/290/0/about.rdf ;
  ecrm:P46i_forms_part_of data:feature/VP_76 ;
  ecrm:P109_has_current_or_former_curator data:organisation/DE-290/Fachreferate .
data:collection/290/0/1
  a ecrm:E78_Collection ;
  skos:prefLabel "Freihand"@de ;
  rdfs:isDefinedBy data:collection/290/0/1/about.rdf ;
  ecrm:P46i_forms_part_of data:collection/290/0 ;
  ecrm:P46i_forms_part_of (data:feature/VP_76/SecondFloor data:feature/VP_76/ThirdFloor) ;  
  ecrm:P109_has_current_or_former_curator data:organisation/DE-290/Fachreferate .
data:collection/290/0/1/Sn
  a ecrm:E78_Collection ;
  skos:prefLabel "Signaturgruppe Sn"@de , "Shelf Mark Sn"@en ;
  rdfs:isDefinedBy data:collection/290/0/1/Sn/about.rdf ;
  ecrm:P46i_forms_part_of data:collection/290/0/1 ;
  ecrm:P46i_forms_part_of data:feature/VP_76/ThirdFloor; ;
  ecrm:P109_has_current_or_former_curator data:organisation/DE-290/Fachreferate/Informatik .
data:collection/290/0/2
  a ecrm:E78_Collection ;
  skos:prefLabel "Textbook Collection"@en , "Lehrbuchsammlung"@de ;
  rdfs:isDefinedBy data:collection/290/0/2/about.rdf ;
  ecrm:P46i_forms_part_of data:collection/290/0 ;
  ecrm:P46i_forms_part_of data:feature/VP_76/GroundLevel; ;
  ecrm:P109_has_current_or_former_curator data:organisation/DE-290/Fachreferate .

Bestandsnachweise konkret
Die bisherigen Daten werden nach ihrer initialen Erstellung relativ selten aktualisiert und stehen somit als administrative Daten bei der
Beschreibung der Bestandsnachweise zur Verlinkung zur Verfügung. Also was bleibt nun noch konkret für den eigentlichen Bestandsnachweis zu tun?
Das folgende Beispiel zeigt, dass bis auf die individuelle Signatur und den Status der zur Verfügung stehenden Services nur noch Links zu erfassen sind. Folgende Links werden benötigt7:

  • Link zum Besitzer
  • Link zur Kollektion
  • Link zur Manifestation*
  • Link zur Publication Expression*
  • ggf. Link zum Production Event*
data:item/13000956
  a efrbroo:F5_Item ;
  skos:prefLabel "Sn 23555" ;
  rdfs:isDefinedBy data:item/13000956/about.rdf ;
  ecrm:P52_has_current_owner data:organisation/DE-290 ;
  ecrm:P46I_forms_part_of data:collection/290/0/1/Sn ;
  efrbroo:R7_is_example_of data:manifestation/32d8f198-5ec0-4afc-8fe9-0b0388852459 ;
  efrbroo:R6_carries data:expression/c90e09d7 ;
  efrbroo:R28i_was_produced_by data:event/32d8f198-5ec0-4afc-8fe9-0b0388852459 ;
  ecrm:P70i_is_documented_in data:item/13000956/about.rdf .

Fazit und Ausblick
Die vermeintliche Komplexität der Modelle mittels CIDOC CRM und seinen Erweiterungen im Beitrag „Bestandsnachweise von Bibliotheken als Linked Data“ lässt sich somit bei genauerer Betrachtung in die vier Bereiche location, organization, collection und holding aufteilen und somit erheblich reduzieren.

Für die tatsächliche Erfassungsarbeit der Bestände durch Bibliothekarinnen und Bibliothekare können in dieser Form sehr einfach gehaltene Formulare dienen, die an den Linking-Felder mit „autosuggest„-Funktionen hinterlegt sind. Im Sinne der Forderung von Dorothea Salo bei der SWIB 138 nach Tools, wäre das ein sehr wertvolles Szenario und ein wesentlicher Schritt vom „Cataloging“ zum „Catalinking„.

  1. Mail vom 22.11.2013 im Mailarchiv []
  2. Ich meine hier nicht die zahlreichen „Application Profiles“ sondern die tatsächlich neuen Ontologien. []
  3. Zur Anwendung des CIDOC CRM als Referenzontologie bzw. Anwendungsontologie vergleiche auch Hohmann, Georg (2010): Die Anwendung des CIDOC CRM für die semantische Wissensrepräsentation in den Kulturwissenschaften. In: Ohly, Peter; Sieglerschmidt, Jörn (eds.): Wissensspeicher in digitalen Räumen. Nachhaltigkeit, Verfügbarkeit, semantische Interoperabilität. Proceedings der 11. Tagung der Deutschen Sektion der Internationalen Gesellschaft für Wissensorganisation Konstanz 20.-22. Februar 2008. Würzburg: Ergon. pp. 210-222. []
  4. CRM: „This class comprises pieces of land or sea floor.“ []
  5. CRM: „This class comprises identifiable features that are physically attached in an integral way to particular physical objects.“ []
  6. CRM: „This class comprises physical features that are purposely created by human activity, such as scratches, artificial caves, artificial water channels, etc.“ []
  7. Für die mit * gekennzeichneten Links vgl. den Abschnitt „WEM + I im CIDOC CRM-Universum“ in Bestandsnachweise von Bibliotheken als Linked Data. []
  8. vgl. z.B. mein Tagungsbericht “In LOD we trust” – Ein Bericht von der SWIB13 []

Library Holdings as Linked Data

Translated by André Hagenbruch / Deutsche Version Deutsche Version

In his blog post „Local library data in the new global framework“ Lukas Koster was spot on when he noted:

It doesn’t really make sense if all libraries in the world publish identical metadata side by side, does it?
In essence only really unique data is worth publishing. You link to the rest.

Among the few examples for the typical library to publish unique Linked Open Data are special collections and the increasingly important field of research data. But the one unique data resource that all libraries have in common is holdings information. As more and more bibliographic data is fed to WWW search engines by publishers, holdings information is an increasingly relevant source for networked and mobile applications.

Small wonder that there already are several approaches to modelling holdings. Among these are:

If you look at my earlier posts in this blog, I have already shown the flexibility and expressiveness of CRM, FRBRoo and PRESSoo. These articles mostly focused on the desciption of bibliographic objects and concepts and only hinted at their usefulness for holdings information. But the ontologies of the CRM universe in conjunction with the concepts from DAIA are very well suited to describe holdings information.

WEM + I in the CIDOC CRM Universe

Taking the University Library Dortmund as a member of the hbz library network I will show how the concepts work, expression, manifestation (WEM), and items (I) are being distributed among these two organisations.3 Whereas the library co-operative takes care of both the bibliographic description of the works, expressions, and manifestations as well as of its own collection descriptions, University Library Dortmund primarily documents their local holdings and builds availability services around them. Thus we avoid the aforementioned process of repeatedly publishing of identical data.

The following diagram illustrates the connection between these two services. It’s limited to the major components and builds on the models described in FRBRoo — eine Anwendung.4

Verbund-Lokal-System_en

On the right side of the diagram you can see the actual holdings which are being modeled by the concept F5 Item from FRBRoo. Moreover, PRESSoo offers a suitable item for journal holdings, i.e. Z9 Storage Unit. The CRM extension CRMdig offers a suitable model for the presentation of digital objects on the level of exemplars.

Holdings information

To describe holdings information with the CRM I use the properties of the exemplar entity’s parent. It holds that:

  • F5 Item subClassOf E84 Information Carrier subClassOf E22 Man-Made Object
  • Z9 Storage Unit subClassOf E22 Man-Made Object
  • D13 Digital Information Carrier subClassOf E84 Information Carrier subClassOf E22 Man-Made Object
  • E22 Man-Made Object subClassOf E19 Physical Object subClassOf E18 Physical Thing

Usually such physical objects are being kept in a certain location and can eventually be made available to the user. These locations can be described with CRM concept E27 Site. Quoting the CRM:

In contrast to the purely geometric notion of E53 Place, this class describes constellations of matter on the surface of the Earth or other celestial body, which can be represented by photographs, paintings and maps.

Thus we can make statements about cohesion or ownership with respect to locations like branches, sections, departments, or stacks using E27 Site. To this end we can employ the following relations of the CRM (E27 Site subClassOf E18 Physical Thing):

  • E18 Physical Thing P46 is composed of (forms part of) E18 Physical Thing
  • E18 Physical Thing P52 has current owner (is current owner of) E39 Actor
  • E18 Physical Thing P58 has section definition (defines section) E46 Section Definition

Holdings information

Example 1: The FRBR family of conceptual models

<http://data.ub.tu-dortmund.de/resource/item/20129967> [
  a frbroo:F5_Item ;
  rdfs:label "A 12726" ;
  ecrm:P52_has_current_owner <http://lobid.org/organisation/DE-290> ;				
  ecrm:P46i_forms_part_of [
	a ecrm:E27_Site ;
	ecrm:P58_has_section_definition [
		a ecrm:E46_Section_Definition ;
		rdfs:label "Second Floor"
	]  ;
	ecrm:P46i_forms_part_of [
		a ecrm:E27_Site ;
		ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "Central Library"
		] ;
		ecrm:P46i_forms_part_of [
		  a ecrm:E27_Site ;
		  ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "TU Dortmund, University Library"
		  ] ;
		] ;
	] ;
  ] ;  
] .

Here we describe the item with the call number „A 12726“ located on the second floor of the central library of the University Library Dortmund. We could enrich the description of the central library by adding for instance geo information as it is one of eight sites making up the entire University Library. This geo information then describes an E53 Place linked to a P53 has former or current location.

Ongoing serials (F18 Serial Work) or journals as their special case have to be viewed from a point of view of storage practices. With the exception of the most recent isuues, items of journal issues are mostly available as a series of bound units. Usually these series are not further specified, but hold a common call number.5
The following diagram shows both the most current issue in its original binding and the result of the binding process and its relation to Z9 Storage Unit. By transforming the items to a new object the latter becomes an item of a new cumulative Publication Work. This Publication Work in turn is part of an ongoing serial work of type series.

Items_of_Serial_Works

The holdings information is now distributed on two objects:

  • Z9 Storage Unit is being described similarly to F5 Item in example 1.
  • The holdings history is being assigned to the newly created F18 Serial Work by means of ECPO.6

In the following example the journal’s holdings information is being illustrated with a partial Z9 Storage Unit, leaving out the chronology.

Example 2: Bibliotheksdienst
According to the model outlined above this journal has two Z9 Storage Units, as it has been acquired by two branches of the University Library Dortmund.

<http://data.ub.tu-dortmund.de/resource/storageunit/ZA_377> [
  a pressoo:Z9_Storage_Unit ;
  rdfs:label "ZA 377" ;
  ecrm:P52_has_current_owner <http://lobid.org/organisation/DE-290> ;	
  ecrm:P46I_forms_part_of [
	a ecrm:E27_Site ;
	ecrm:P58_has_section_definition [
		a ecrm:E46_Section_Definition ;
		rdfs:label "Basement Level 1"
	]  ;
	ecrm:P46I_forms_part_of [
		a ecrm:E27_Site ;
		ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "Central Library"
		] ;
		ecrm:P46I_forms_part_of [
		  a ecrm:E27_Site ;
		  ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "TU Dortmund, University Library"
		  ] ;
		] ;
	] ;
  ] ;  
] . 

<http://data.ub.tu-dortmund.de/resource/storageunit/Bibliotheksdienst> [
  a pressoo:Z9_Storage_Unit ;
  rdfs:label "Bibliotheksdienst" ;
  ecrm:P52_has_current_owner <http://lobid.org/organisation/DE-290> ;				
  ecrm:P46I_forms_part_of [
	a ecrm:E27_Site ;
	ecrm:P58_has_section_definition [
		a ecrm:E46_Section_Definition ;
		rdfs:label "R. 501"
	]  ;
	ecrm:P46I_forms_part_of [
		a ecrm:E27_Site ;
		ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "Bibl. Sozialforschungsstelle"
		] ;
		ecrm:P46I_forms_part_of [
		  a ecrm:E27_Site ;
		  ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "TU Dortmund, University Library"
		  ] ;
		] ;
	] ;
  ] ;  
] .

Services for Items

Holdings information decoupled from pertinent services of the organisation isn’t much worth in the Linked Open Data Cloud. Only through coupling items with services such as loan can we offer surplus values that are not normally available through the bibliographic description alone.

As I already said in my previous post, currently a few micro ontologies dealing with the modelling of library services and bibliographic metadata in the linked data context are being developed by the German library community. To describe these services and statuses, we can use DAIA, DSO, and SSSO.

The following diagram shows the linkage of the Document Service Ontology to the Z9 Storage Unit via DAIA. For this we have to assume that the concept of Document in DSO and DAIA is compatible with Z9 Storage Unit.7

Z9-DAIA

The linked Document Services are being described by the Simple Service Status Ontology. Thus, we can make statements such as ‚Item A is unavailable until date X.‘

Example 3: loanable item with property daia:availableFor

<http://data.ub.tu-dortmund.de/resource/item/20129967> [
  a frbroo:F5_Item ;
  rdfs:label "A 12726" ;
  daia:availableFor [
    a dso:Loan ;
  ] ;
  ecrm:P52_has_current_owner <http://lobid.org/organisation/DE-290> ;				
  ecrm:P46I_forms_part_of [
	a ecrm:E27_Site ;
	ecrm:P58_has_section_definition [
		a ecrm:E46_Section_Definition ;
		rdfs:label "Second Floor"
	]  ;
        ...
  ] ;  
] .

Example 4: issue of a serial work available for presentation and interlibrary loan

<http://data.ub.tu-dortmund.de/resource/storageunit/ZA_377> [
  a pressoo:Z9_Storage_Unit ;
  rdfs:label "ZA 377" ;
  daia:unavailableFor [
    a dso:Loan ;
  ] ;
  daia:availableFor [
    a dso:Presenation ;
  ] ;
  daia:availableFor [
    a dso:Interloan;
  ] ;
  ecrm:P52_has_current_owner <http://lobid.org/organisation/DE-290> ;	
  ecrm:P46I_forms_part_of [
	a ecrm:E27_Site ;
	ecrm:P58_has_section_definition [
		a ecrm:E46_Section_Definition ;
		rdfs:label "Basement Level 1"
	]  ;
        ...
  ] ;  
] .

Conclusion
I have shown that we can make meaningful statements about holdings information using the existing ontologies and that there is no need for developing new vocabularies. As an afterthought, we might even also describe acquisition information within the CIDOC CRM framework. The simplest approach would be to use the concept E8 Acquisition Event to model an acquisition event and to describe it via EDIFACT data as an E31 Document.

  1. Wiki of the DINI-KIM-WG []
  2. EDINA is the Jisc-designated national data centre at the University of Edinburgh. []
  3. The catalog of the NRW library network is being operated by the Hochschulbibliothekszentrum NRW (hbz) and is an effort of the participating libraries cataloging into a central integrated library system. The data captured there are then being replicated to the local library systems. []
  4. currently only in German []
  5. The volumes of „simple series“ can be described as objects of ‚classic book format‘ which are not being bound as books in frequent intervals. Thus, they won’t be considered in this article. []
  6. see also: „PRESSoo und ECPO – Zwei weitere Ontologien zur Beschreibung von fortlaufenden Sammelwerken“ (currently only in German) []
  7. The DSO specification says: ‚The set of documents is not limited to a specific class […]‘. Thus, the assumption holds true. The DAIA specification would have to be extended insofar as it only considers frbr:items valid at this point. []

Bestandsnachweise von Bibliotheken als Linked Data

English Version English Version

Lukas Koster formulierte in seinem Blog-Beitrag „Local library data in the new global framework“ sehr treffend:

It doesn’t really make sense if all libraries in the world publish identical metadata side by side, does it?
In essence only really unique data is worth publishing. You link to the rest.

Unter den wenigen Beispielen, in denen typische Bibliotheken unikale (Meta-)Daten als Linked Open Data veröffentlichen können, sind spezielle
Sammlungen und auch die immer wichtiger werdenden Forschungsinformationen wissenschaftlicher Einrichtungen. Eine wichtige Datenmenge, die alle Bibliotheken gemeinsam haben, ist aber tatsächlich die der Bestandsnachweise.
In Zeiten, in denen bibliographische Informationen direkt von den Verlagen in die Suchmaschinen des WWW wandern, sind die Bestandsnachweise als Quelle für vernetzte und insbesondere auch mobile Anwendungen interessantes Material.
So wundert es nicht, dass es mittlerweile mehrere Ansätze für die Beschreibung der Bestände gibt. Genannt seien hier:

Betrachtet man u.a. die bisherigen Beiträge dieses Blogs, so wurde die Flexibilität und Aussagekraft von CRM, FRBRoo und PRESSoo bereits bewiesen. Diese Beiträge haben sich bisher weitestgehend auf die Beschreibung von bibliographischen Objekten und Konzepten bezogen, wobei der Bereich des Bestandsnachweises nur kurz angerissen wurde.

Aber auch mit den Ontologien des CRM-Universums in Verbindung mit den Konzepten rund um DAIA können die Bestandsnachweise sehr gut beschrieben werden.

WEM + I im CIDOC CRM-Universum
Am Beispiel des Katalogs der UB Dortmund und des „hbz-Verbundkatalogs“3 soll zunächst gezeigt werden, wie eine zentrale Stelle identische Metadaten verschiedener Quellen — hier also konkret die Bereiche Work, Expression, Manifestation (WEM) — als Linked Data publizieren kann und die unikalen Metadaten der Items (I) durch die Lokalsysteme publiziert werden können.
Das folgende Diagramm stellt die Verlinkung der beiden Metabereiche dar. Dabei beschränkt es sich auf die wesentlichen Komponenten und setzt die Modelle aus FRBRoo — eine Anwendung voraus.

Verbund-Lokal-System

Das obige Diagramm zeigt auf der Seite der tatsächlichen Bestände nur das Konzept der F5 Item aus FRBRoo. Mit dem Erscheinen von PRESSoo gibt es auch für die Bestände von Zeitschriften ein geeignetes „Item“, nämlich Z9 Storage Unit. Auch für digitale Objekte gibt es mit der CRM-Erweiterung CRMdig eine geeignete Darstellung auf Exemplarebene.

Bestandsnachweise
Um nun die Bestandsnachweise mit dem CRM zu beschreiben, macht man sich die Eigenschaften der Eltern-Entitäten der Exemplar-Entitäten zu nutze. Es gilt:

  • F5 Item subClassOf E84 Information Carrier subClassOf E22 Man-Made Object
  • Z9 Storage Unit subClassOf E22 Man-Made Object
  • D13 Digital Information Carrier subClassOf E84 Information Carrier subClassOf E22 Man-Made Object
  • E22 Man-Made Object subClassOf E19 Physical Object subClassOf E18 Physical Thing

Üblicherweise werden solche physischen Dinge an bestimtmen Orten aufbewahrt und gegebenenfalls zugänglich gemacht. Die Aufbewahrungsorte können mit dem CRM-Konzept E27 Site beschrieben werden. Im CRM heißt es dazu:

In contrast to the purely geometric notion of E53 Place, this class describes constellations of
matter on the surface of the Earth or other celestial body, which can be represented by
photographs, paintings and maps.

Somit können Aufbewahrungsorte wie Zweigstellen, Sektionen, Abteilungen oder Magazine über E27 Site Aussagen über Zusammenhänge und Eigentumsverhältnissen zugeordnet werden. Dazu werden folgende Relationen des CRM verwendet (E27 Site subClassOf E18 Physical Thing):

  • E18 Physical Thing P46 is composed of (forms part of) E18 Physical Thing
  • E18 Physical Thing P52 has current owner (is current owner of) E39 Actor
  • E18 Physical Thing P58 has section definition (defines section) E46 Section Definition

Bestandsnachweis

Beispiel 1: The FRBR family of conceptual models

<http://data.ub.tu-dortmund.de/resource/item/20129967> [
  a frbroo:F5_Item ;
  rdfs:label "A 12726" ;
  ecrm:P52_has_current_owner <http://lobid.org/organisation/DE-290> ;				
  ecrm:P46i_forms_part_of [
	a ecrm:E27_Site ;
	ecrm:P58_has_section_definition [
		a ecrm:E46_Section_Definition ;
		rdfs:label "Second Floor"
	]  ;
	ecrm:P46i_forms_part_of [
		a ecrm:E27_Site ;
		ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "Central Library"
		] ;
		ecrm:P46i_forms_part_of [
		  a ecrm:E27_Site ;
		  ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "TU Dortmund, University Library"
		  ] ;
		] ;
	] ;
  ] ;  
] .

Das RDF beschreibt das Exemplar mit der Signatur „A 12726“, welches sich in der Zentralbibliothek der Universitätsbibliothek der TU Dortmund im zweiten Obergeschoß befindet. Die Beschreibung der Zentralbibliothek könnte beispielsweise noch um „Geoinformationen“ ergänzt werden, da es sich um einen von acht Standorten der gesamten Universitätsbibliothek handelt. Diese „Geoinformationen“ sind dann ein mit P53 has former or current location verknüpfter E53 Place.

Bei fortlaufenden Sammelwerken (F18 Serial Work) bzw. beim Spezialfall der Zeitschriften muss man zunächst die Praxis der Aufbewahrung betrachten. Die Exemplare von Zeitschriftenheften liegen — abgesehen von den aktuellsten Heften – meist als Reihe neu gebundener Einheiten vor. Diese Reihen sind in der Regel nicht näher spezifiziert, besitzen allerdings eine gemeinsame Signatur.4
Das nachstehende Diagramm zeigt, neben einem aktuellen Heft in Originalbindung, insbesondere das Ergebnis des Bindeprozesses und den Zusammenhang zur Z9 Storage Unit.
Durch die Transformation der Exemplare zu einem neuen Objekt, wird letzteres zu einem Exemplar eines neuen kumulativen Publication Work. Dieses Publication Work ist dabei ein Teil eines neuen fortlaufenden Sammelwerks in Form einer Reihe.

Items_of_Serial_Works

Der Beschreibung der Bestände verteilt sich jetzt auf zwei Objekte:

  • Die Z9 Storage Unit wird ähnlich wie das F5 Item in Beispiel 1 beschrieben.
  • Die Bestands-Chronologie wird mittels ECPO dem neu entstandenen F18 Serial Work zugeordnet.5

Im folgenden Beispiel wird der Bestandsnachweis einer Zeitschrift anhand eines Teils ihrer Z9 Storage Unit gezeigt, wobei die Chronology nicht mit aufgeführt wird.

Beispiel 2: Bibliotheksdienst
Diese Zeitschrift hat nach obigem Modell zwei Z9 Storage Unit, da Sie in zwei Standorten der Universitätsbibliothek Dortmund angeschafft wurde.

<http://data.ub.tu-dortmund.de/resource/storageunit/ZA_377> [
  a pressoo:Z9_Storage_Unit ;
  rdfs:label "ZA 377" ;
  ecrm:P52_has_current_owner <http://lobid.org/organisation/DE-290> ;	
  ecrm:P46I_forms_part_of [
	a ecrm:E27_Site ;
	ecrm:P58_has_section_definition [
		a ecrm:E46_Section_Definition ;
		rdfs:label "Basement Level 1"
	]  ;
	ecrm:P46I_forms_part_of [
		a ecrm:E27_Site ;
		ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "Central Library"
		] ;
		ecrm:P46I_forms_part_of [
		  a ecrm:E27_Site ;
		  ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "TU Dortmund, University Library"
		  ] ;
		] ;
	] ;
  ] ;  
] . 

<http://data.ub.tu-dortmund.de/resource/storageunit/Bibliotheksdienst> [
  a pressoo:Z9_Storage_Unit ;
  rdfs:label "Bibliotheksdienst" ;
  ecrm:P52_has_current_owner <http://lobid.org/organisation/DE-290> ;				
  ecrm:P46I_forms_part_of [
	a ecrm:E27_Site ;
	ecrm:P58_has_section_definition [
		a ecrm:E46_Section_Definition ;
		rdfs:label "R. 501"
	]  ;
	ecrm:P46I_forms_part_of [
		a ecrm:E27_Site ;
		ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "Bibl. Sozialforschungsstelle"
		] ;
		ecrm:P46I_forms_part_of [
		  a ecrm:E27_Site ;
		  ecrm:P58_has_section_definition [
			a ecrm:E46_Section_Definition ;
			rdfs:label "TU Dortmund, University Library"
		  ] ;
		] ;
	] ;
  ] ;  
] .

Services für die Exemplare
Bestandsnachweise sind eigentlich ohne die Angabe damit verbundener Dienste der Einrichtung in der Linked Open Data Cloud nicht viel wert. Erst durch die mit den Exemplaren verbundenen Services, wie beispielsweise der Ausleihmöglichkeit, werden Mehrwerte angeboten, die durch die bibliographische Beschreibung allein nicht darstellbar sind.

Wie schon im vorigen Beitrag bemerkt, entwickeln sich aktuell im deutschen Bibliothekswesen einige Mikroontologien rund um die Darstellung von Bibliotheksservices und bibliographischen Metadaten im Linked Data Kontext. Um die mit den tatsächlichen Beständen verbundenen Services und Status zu beschreiben, können die in diesem Rahmen entwickelten Ontologien DAIA, DSO und SSSO verwendet werden.

Das folgende Diagramm zeigt die Anbindung der Document Service Ontology an die Z9 Storage Unit mittels DAIA. Hierbei wird vorausgesetzt, dass der Document-Begriff in DSO und in DAIA auch Z9 Storage Unit berücksichtigt6

Z9-DAIA

Die zugeordneten Document Services werden mit der Simple Service Status Ontology beschreiben. Somit sind dann Aussagen wie „Das Exemplar A ist bis zum Datum X nicht ausleihbar.“ möglich.

Beispiel 3: ausleihbares Exemplar mittels daia:availableFor

<http://data.ub.tu-dortmund.de/resource/item/20129967> [
  a frbroo:F5_Item ;
  rdfs:label "A 12726" ;
  daia:availableFor [
    a dso:Loan ;
  ] ;
  ecrm:P52_has_current_owner <http://lobid.org/organisation/DE-290> ;				
  ecrm:P46I_forms_part_of [
	a ecrm:E27_Site ;
	ecrm:P58_has_section_definition [
		a ecrm:E46_Section_Definition ;
		rdfs:label "Second Floor"
	]  ;
        ...
  ] ;  
] .

Beispiel 4: Zeitschriftenbestand für die Präsenznutzung und Fernleihe

<http://data.ub.tu-dortmund.de/resource/storageunit/ZA_377> [
  a pressoo:Z9_Storage_Unit ;
  rdfs:label "ZA 377" ;
  daia:unavailableFor [
    a dso:Loan ;
  ] ;
  daia:availableFor [
    a dso:Presenation ;
  ] ;
  daia:availableFor [
    a dso:Interloan;
  ] ;
  ecrm:P52_has_current_owner <http://lobid.org/organisation/DE-290> ;	
  ecrm:P46I_forms_part_of [
	a ecrm:E27_Site ;
	ecrm:P58_has_section_definition [
		a ecrm:E46_Section_Definition ;
		rdfs:label "Basement Level 1"
	]  ;
        ...
  ] ;  
] .

Fazit
Es konnte gezeigt werden, dass ohne ein neues Vokabular und mit bereits bestehenden Ontologien ausgereifte Aussagen über Bestände gemacht werden können.
Übrigens ließen sich auch Erwerbungsinformationen durch die Modell-Familie des CIDOC CRM beschreiben. Als einfachste Variante nehme man für das Erwerbungsereignis das Konzept E8 Acquisition Event und beschreibe es mittels EDIFACT-Daten als E31 Document.

  1. Wiki der DINI-KIM-AG []
  2. EDINA is the Jisc-designated national data centre at the University of Edinburgh. []
  3. Der Katalog des Bibliotheksverbunds NRW wird vom
    Hochschulbibliothekszentrum NRW (hbz) betrieben und entsteht durch eine gemeinsame Katalogisierung der Verbundbibliotheken in ein zentrales
    Bibliothekssystem (ILS). Die in diesem System erfassten Daten werden anschließend in den Lokalsystemen repliziert. []
  4. Bei „einfachen“ Reihen oder Serien handelt es sich bei den Bänden in der Regel um Objekte in „klassischer Buchform“, die nicht in regelmäßigen Abständen zu neuen Einheiten gebunden werden. Sie werden daher aus dieser Betrachtung herausgelassen. []
  5. vgl. auch „PRESSoo und ECPO – Zwei weitere Ontologien zur Beschreibung von fortlaufenden Sammelwerken“ []
  6. In der Spezifikation zu DSO heißt es: „The set of documents is not limited to a specific class[…]“. Daher ist hier die Annahme berechtigt. Bei DAIA müsste die Spezifikation dahingehend erweitert werden, da hier nur frbr:items verwendet werden. []

CRMdig und CRMgeo — zwei Erweiterungen für das CIDOC CRM

Über die Rolle und Mächtigkeit des CIDOC CRM für die Beschreibung von Zusammenhängen im Bereich des kulturellen Erbes habe ich u.a. im Beitrag FRBRoo — eine Anwendung geschrieben und gezeigt, dass auch bibliographische Zusammenhänge mittels der Erweiterung FRBRoo sehr gut darstellbar sind.
Doch es gibt auch noch offene bzw. nur unzureichend modellierte Fragestellungen. Zum einen ist die Ausgestaltung des Bereichs der Geoinformationen überraschend überschaubar. Zum anderen ist auch die wichtige Frage der Provenienz im Hauptmodell nicht weit genug gefasst.
Um die beiden Lücken zu schließen, wurden CRMdig („A generic digital provenance model for scientific observation“) und CRMgeo („A spatio-temporal refinement of the CIDOC CRM Model“) als Erweiterungen für das CRM entwickelt.

Informationen zur Provenienz im CRM

Wie seinerzeit auch im DFG-Projekt „ArcheoInf“ gesehen, macht eine Veröffentlichung von Forschungsdaten keinen Sinn, wenn diese nicht verstanden werden können. Um die Daten verstehen zu können sind Informationen zur inhaltlichen Bedeutung und zu den Umständen der Entstehung der Daten notwendig, also Angaben zur Provenienz. Die W3C Provenance Incubator Group schreibt dazu: „Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource.“
Was beduetet das nun im im Einzelnen? Welche Informationen müssen erfasst werden?
In ihrem auf der TaPP-Konferenz 2011 vorgestellten Papier „CRMdig: A generic digital provenance model for scientific observation“ beschreiben Doerr und Theodoridou fünf zu beantwortende Frage:

  • WER: Personen und Insitutionen, die bei der Entstehung der Daten beteiligt waren
  • WO: Orte, an denen die Daten entstanden sind
  • WANN: zeitliche Angaben zur Entstehung der Daten
  • WAS: Dinge, die in dem Prozess eine Rolle spielen
  • WIE: Beschreibung des Prozesses und der eventuell verwendeten Technik

Das folgende Bild zeigt das Netz von Objekten und Prozessen für zwei Digitaliserungsereignisse und die darauf folgenden Verarbeitungsschritte. Bei der Digitaliserung wurden zwei verschiedene Techniken verwendet, die letztlich zwei 3D Modelle des Objektes erzeugen.

Digitalisierung eines Objektes

Digitalisierung eines Objektes durch zwei Prozesse

Das CRMdig stellt bei der Beschreibung die Entität Digital Machine Event in den Mittelpunkt und geht davon aus, dass jedes dieser Ereignisse durch eine menschliche Person angestoßen wird. Das folgende Diagramm zeigt die Modellierung in der üblichen CRM-Manier, wobei hier die Entitäten mit einem vorangestellten D und die Eigenschaften mit einem vorangestellten L bezeichnet werden.

Erzeugen eines Objektes durch maschinelle Prozesse

Erzeugen eines Objektes durch maschinelle Prozesse

Für die Anwendung im Kontext von Linked Data wird auch eine RDFS-Version angeboten.

Geoinformationen im CRM

Die wachsenden Möglichkeiten des (Mobile) Webs wecken auch die Bedürfnisse nach Anreicherungen von Informationen des kulturellen Erbes, um präzise und gut identifizerbare Beschreibungen von Örtlichkeiten, Landschaften oder historischen Ereignissen oder Überbleibseln anzubeiten. Für die Beschreibung solcher Gegebenheiten gibt es auf der einen Seite die Geoinformationssysteme (GIS), die eher geschlossene Systeme darstellen und für die Vermessung und Repräsentation von kulturhistorischen und archäologischen Erscheinungen aber auch für Anwendungen anderer Geowissenschaften verwendet werden. Auf der anderen Seite sind Archive, Bibliotheken und Museen bemüht, detailierte Metadaten über physikalische und konzeptionelle Objekte zu erfassen, wobei Sie zwar stark auf Typologien, individuelle Objekte, Personen und Ereignisse sowie präzisen Datums- und Zeitraumangaben achten, aber wenig reichhaltige Ortsangaben verwenden.
Diese Praxis stößt sehr schnell an ihre Grenzen, wenn nun versucht wird, die Beschreibungen aus den Archiven, Bibliotheken und Musseen mit Stadtplänen o.ä. zu verbinden. Aussagen wie „Die Leute wissen schon wo Parthenon liegt.“ oder „Du wirst es sehen, wenn Du in Athen bist.“ sind im Bereich der Informationssysteme nicht wirklich hilfreich.
Beide Bereiche verfügen aber bereits über etablierte Standards zur Beschreibung von solchen Sachverhalten: im Bereich der Geowissenschaften ist dies der OGC/ISO Standard und im Bereich Archive, Bibliotheken und Museen ist es der ISO-Standard CIDOC CRM. Allerdings unterscheiden sich dabei die Sichtweisen und lassen sich zudem auch nicht so richtig in Einklang bringen.

Diese Erkenntnis hat man beim ICS-FORTH (Institute of Comupter Science, Foundation for Research and Technology, Griechenland) dazu genutzt, um diese Lücke zu schließen. Herausgekommen ist mit CRMgeo eine Erweiterung des CIDOC CRM. Die Idee dabei ist, dass Fragen wie „Ist das der Ort, an der die Varus Schlacht stattgefunden hat?“ oder „Ist das der Ort, an dem Lord Nelson starb?“ auf ihren Wahrheitsgehalt überprüft werden können. Es wird schnell klar, dass – wie im Beispiel der Varusschlacht – auch ungenaue Informationen bzw. – wie im Fall Lord Nelson – auch verschiedene Sichten auf einen Ortskontext berücksichtigt werden müssen.

Zentrale Ereignisse in der Diskussion um die Varausschlacht

Zentrale Ereignisse in der Diskussion um die Varausschlacht

Ereignisse der Trafalgar Schlacht aus Sicht des Schiffs und des Meeresgrunds

Ereignisse der Schlacht von Trafalgar aus Sicht des Schiffs und des Meeresgrunds

Der Report zu CRMgeo zeigt an den beiden genannten Beispielen die Zusammenhänge und die Mächtigkeit des Modells und erweitert das CRM so um eine weitere wichtige Komponente.

FRBRoo — eine Anwendung

In den letzten Jahren habe ich mich im Rahmen des von der DFG geförderten Projektes „ArcheoInf – Informationszentrum für die Archäologie“ mit dem CIDOC CRM und der zugehörigen Erweiterung FRBRoo beschäftigt.

Ziel des Projektes war es, „Primärdaten archäologischer Forschung, die bisher in heterogenen Datenstrukturen vorgehalten wurden, unter Wahrung ihrer Autonomie in einer gemeinsamen Umgebung web-basiert verfügbar“ zu machen. Mit den archäologischen Primärdaten sollten bibliothekarische Informationen und Dienstleistungen sowie geoinformatisches Datenmaterial verbunden werden.

Aufgrund der als „Best Practice“ einzuordnenden Erfahrungen aus den britischen Strukturen zur Erhaltung des kulturellen Erbes (z.B. English Heritage, British Museum), war uns sehr früh bewusst, dass ein System wie ArcheoInf nur auf Basis des CIDOC CRM gelingen kann.

Was ist das CIDOC CRM?

Beim CIDOC Conceptual Reference Model handelt es sich um eine Norm (ISO 21127:2006) für den kontrollierten Austausch von Informationen im Bereich des kulturellen Erbes. Die Ontologie soll unter anderem von Archiven, Bibliotheken und Museen zur Verbesserung der Verfügbarkeit von Wissen angewandt werden. Es wurde vom CIDOC, einem der 30 internationalen Komitees des International Council of Museums (Internationalen Museumsrats, ICOM) entwickelt.

Mit dem CIDOC CRM wird das Ziel verfolgt, die vielfältigen Informationen im Bereich des kulturellen Erbes gemeinsam zu erfassen und einen allgemeinen Rahmen ihrer formalen Semantik zur Verfügung zu stellen, damit jede Information dieses Bereichs den Begriffen des CIDOC CRM zugeordnet wer-den kann. Auf diese Weise werden wichtige Voraussetzungen für die Informationsintegration geschaffen, da auf der Grundlage des CIDOC CRM Werkzeuge zur Schematransformation und -integration entwickelt werden können.

Das CRM beruht auf zwei Hierarchien von Entitäten und Eigenschaften und erlaubt ein hohes Maß an semantischer Präzision. Es eignet sich daher als eine Art Zwischenformat, dessen Verwendung die Anzahl der notwendigen Mappings dramatisch reduziert, wenn verschiedene Quellformate und mehrere Zielsprachen benötigt werden. Die wichtigste Eigenschaft des CIDOC CRM ist allerdings die Ereigniszentriertheit, d.h. es wird davon ausgegangen, dass jedes Objekt nur dann existiert, wenn vorher ein Ereignis stattgefunden hat, welches das Objekt zum Resultat hat.

Aber es fehlen Strukturen für bibliographische Daten!

Das CRM erlaubt Mappings beliebiger Datenmodelle. Für einige der im Bereich des kulturellen Erbes einschlägigen Modelle liegen generische Mappings vor, die von den Entwicklern des CRM veröffentlicht wurden. Die im Rahmen des CRM-Entwicklungsprojekts entworfenen Mappings für Dublin Core (DC), Encoded Archival Description (EAD), Lightweight Information Describing Objects (LIDO) und anderer Modelle und Formate orientieren sich an den im CRM-Entwicklungsprozess ausgearbeiteten Empfehlungen.

FRBRoo ist die objektorientierte Version der FRBR (siehe auch Tillet: What is FRBR? und Wiesenmüller: Zehn Jahre ‚Functional Requirements for Bibliographic Records‘) und ermöglicht die gemeinsame Darstellung von Bibliotheks- und Museumsdokumentation. Damit ist es möglich, interoperable Informationssysteme für alle Nutzerinnen und Nutzer zu implementieren, die ein Interesse daran haben, auf gemeinsame oder verwandte Inhalte kultureller Einrichtungen zuzugreifen.

Mit der Entwicklung der FRBRoo ging eine gegenseitige Anreicherung der FRBR und des CIDOC CRM einher:

  • Ergänzung der FRBR um Zeit und Ereignisse,
  • begriffliche Abklärung der Entität Manifestation,
  • explizite Modellierung von Aufführungen und Aufzeichnungen, die in den FRBR erwähnt sind,
  • Ergänzung des CRM durch die Entität Werk und
  • Ergänzung des CRM durch einen Identifikator-Vergabeprozess.

FRBRoo fügt damit den FRBR die dynamischen Aspekte des CRM hinzu. Ferner erlaubt es, aufgrund der netzartigen Struktur des CRM, bibliographische Informationen in Linked Data Kontexte zu übertragen.

FRBR, Serials und die fehelende Manifestation

Spätestens mit der Frage nach „FRBR and Serials“ innerhalb des lobid.org-Projektes des hbz, habe ich mich entschlossen, mehr über meine Ergebnisse zum CRM und zu FRBRoo zu berichten.

In den nächsten Beiträgen dieses Blogs werde ich auf Basis der Publikationsformen nach dem bibliothekarischen Standardwerk „Bibliothekarisches Grundwissen“ die Sichtweise der FRBRoo darstellen und zeigen, dass die Fragestellungen bzgl. der „Serials“ sich damit beantworten lassen.

Weiterlesen: