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. []

PRESSoo und ECPO – Zwei weitere Ontologien zur Beschreibung von fortlaufenden Sammelwerken

Die Modellierung von fortlaufenden Sammelwerken mittels des Referenzmodells FRBR gestaltet sich schwierig. Als Gründe seien vor allem die Unvollständigkeit von fortlaufenden Sammelwerken und die Heterogenität der in fortlaufenden Sammelwerken enthaltenen Manifestationen genannt.

Unvollständigkeit von fortlaufenden Sammelwerken
In den FRBR ist festgelegt, dass eine Manifestation in dem Sinn abgeschlossen sein muss, dass man ein Exemplar kaufen und ins Regal stellen kann. Bei fortlaufenden Sammelwerken ist das nicht möglich, solange es weitere Hefte und Jahrgänge im Fall von Zeitschriften oder Bände im Fall von Reihen oder Serien gibt.

Heterogenität der in fortlaufenden Sammelwerken enthaltenen Manifestationen
Teile einer Buchreihe können in einer weiteren Auflage in einer anderen Reihe oder selbständig veröffentlicht werden; Zeitschriftenhefte können als Themenhefte wiederum als Buch veröffentlicht werden.

Denkt man die Werke eher vom Inhalt und weniger von der physikalischen Erscheinungsform, so lassen sich diese Probleme in der bibliographischen Beschreibung umgehen. Mittels FRBRoo ist genau dieser Ansatz möglich (siehe z.B. in FRBRoo — eine Anwendung oder FRBR, Serials und CIDOC CRM).

Fortlaufende Sammelwerke und insbesondere Zeitschriften sind allerdings noch wesentlich komplexer in der bibliographischen Beschreibung, da auch historische Zusammenhänge erfasst werden müssen. Zwar lassen sich diese Informationen auch mit FRBRoo modellieren, jedoch nur sehr abstrakt und umständlich.

PRESSoo
Im März 2013 ist nahezu unbemerkt eine erste Version einer Erweiterung der FRBRoo für fortlaufende Sammelwerke erschienen. Die Erweiterung nennt sich PRESSoo (Version 0.1) und betrachtet neben einer groben Darstellung der Zusammenhänge der bibliographischen Einheiten insbesondere die Veränderungen im Laufe des Lebens eines solchen Werkes.

Dadurch lassen sich folgende Transformationen modellieren:

  • Fortsetzungen (z.B. Titeländerungen)
  • Ersetzungen (Fortsetzung mit neuer Erscheinungsweise)
  • Aufgehen eines fortlaufendes Sammelwerks in ein anderes
  • Abspalten eines Teils zu einem neuen fortlaufenden Sammelwerk
  • Zusammenführen von mehreren fortlaufenden Sammelwerken
  • Aufteilen eines fortlaufendes Sammelwerks in mehrere Neue

Zusätzlich lassen sich auch temporäre Veränderungen modellieren.

Für Fortsetzungen wird der Prozesss in PRESSoo mittels einer neuen Ereignis-Entität Z1 Serial Transformation modelliert. Diese Ereignisse stehen in natürlicher Beziehung zu den letzten F30 Publication Events des Vorgängerwerkes bzw. zu den ersten F30 Publication Events des Nachfolgewerkes. Dabei werden diese F30 Publication Events mittels Z6 Starting of Publication und Z7 Ending of Publication präzisiert.

PRESSoo-Figure-4

Beispiel 1:
Förderschulmagazin : individuelle Förderung von Kindern mit Lernschwierigkeiten
früher: Sonderschulmagazin : Compacts, Arbeitsvorlagen, Verfahren, Formen, Techniken für d. Unterrichtspraxis
früher: Ehrenwirth-Sonderschulmagazin : Zeitschr. für d. Unterrichtspraxis

PRESSoo-Beispiel-1

PRESSoo-Beispiel-1b

<http://ld.zdb-services.de/resource/800272-1> [
  a frbroo:F18_Serial_Work ;
  rdaGr1:preferredTitleForTheWork "Ehrenwirth-Sonderschulmagazin : Zeitschr. für d. Unterrichtspraxis" ;
  pressoo:Y1i_was_continued_through [
    a pressoo:Z1_Serial_Transformation ;
	pressoo:Y2_initiated_as_continuation <http://ld.zdb-services.de/resource/798053-x> ;
  ] ;
  pressoo:Y29_evolved_to <http://ld.zdb-services.de/resource/798053-x> ;
] .

<http://ld.zdb-services.de/resource/798053-x> [
  a frbroo:F18_Serial_Work;
  rdaGr1:preferredTitleForTheWork "Sonderschulmagazin : Compacts, Arbeitsvorlagen, Verfahren, Formen, Techniken für d. Unterrichtspraxis" ;
  pressoo:Y1i_was_continued_through [
    a pressoo:Z1_Serial_Transformation ;
	pressoo:Y2_initiated_as_continuation <http://ld.zdb-services.de/resource/1217829-9> ;
  ] ;
  pressoo:Y29_evolved_to <http://ld.zdb-services.de/resource/1217829-9> ;
] .

<http://ld.zdb-services.de/resource/1217829-9> [
  a frbroo:F18_Serial_Work;
  rdaGr1:preferredTitleForTheWork "Förderschulmagazin : individuelle Förderung von Kindern mit Lernschwierigkeiten" ;
] .

PRESSoo ermöglicht neben den diversen Transformationen auch die Modellierung von Faksimiles, Digitalisierungen1 und sogar kumulierten Fassungen. Die Modellierung von Kumulationen kann bespielsweise für die Bindeeinheiten in Bibliotheksbeständen herangezogen werden. Dabei wird dann das zugehörige F30 Publication Event durch die Buchbinderei durchgeführt.

Beschreibung der Entität Z12 Issuing rule
Im deutschen Bibliothekswesen entwickeln sich derzeit einige Mikroontologien rund um die Darstellung von Bibliotheksservices und bibliographischen Metadaten im Linked Data Kontext. Als Beispiele seien hier DAIA, PAIA, DSO, SSSO, MWO und ECPO genannt. Letztere stellt eine Ontologie zur Beschreibung von Erscheinungsweisen und Bestandsverläufen bei fortlaufenden Sammelwerken dar.2 Somit lassen sich also Entitäten Z12 Issuing Rule aus PRESSoo mit Hilfe von ECPO beschreiben.

Beispiel 2: CCQ – Cataloging & classification quarterly
Erscheinungsverlauf nach ZDB: 1.1980/82; 2.1982; 3.1982/83 –

<http://ld.zdb-services.de/resource/801602-1> [
  a frbroo:F18_Serial_Work;
  rdaGr1:preferredTitleForTheWork "Cataloging & classification quarterly" ;
  pressoo:Y38_has_current_issuing_rule [
    a ecpo:CurrentChronology, pressoo:Z12_Issuing_Rule ;
    dct:hasPart [
      a ecpo:Chronology, pressoo:Z12_Issuing_Rule ;
      ecpo:hasItemizedVolumeNumbering "1" ;
      ecpo:hasItemizedTemporal "1980/82" ;
    ];
    dct:hasPart [
      a ecpo:Chronology, pressoo:Z12_Issuing_Rule ;
      ecpo:hasItemizedVolumeNumbering "2" ;
      ecpo:hasItemizeTemporal "1982" ;
    ];
    dct:hasPart [
      a ecpo:CurrentChronology, pressoo:Z12_Issuing_Rule ;
      ecpo:hasBeginVolumeNumbering "3" ;
      ecpo:hasBeginTemporal "1982/83" ;
    ];
  ];
] .

Fazit
Mit den beiden hier beschriebenen Ontologien ließe sich die deutsche Zeitschriftendatenbank (ZDB) CIDOC CRM-kompatibel als Linked Data veröffentlichen und würde so eine integrierte Verwendung im gesamten Bereich des kulturellen Erbes ermöglichen.

  1. Hier kommt auch die CIDOC CRM-Erweiterung CRMdig zum Einsatz. []
  2. Die Ontologie geht davon aus, dass auch von Zeitschriften Exemplare exisitieren („An Agent always holds a copy of a document called item.“). Im Sinne der FRBR ist das allerdings so nicht korrekt und gilt nur in dem Fall, dass ein fortlaufendes Sammelwerk sein Erscheinen eingestellt hat. Mit PRESSoo wurde daher eine Entität Z9 Storage Unit eingeführt, die die Bestände von z.B. Bibliotheken beschreibt. ECPO ist allerdings so definiert (es wird keine Aussage zur Domain bei den zentralen Relationen gemacht), dass die Konzepte auch für F18 Serial Work anwendbar sind. []

FRBRoo und fortlaufende Sammelwerke

Bei der Definition der FRBRoo wurde darauf geachtet, dass die Begrifflichkeiten der ursprünglichen Functional Requirements for Bibliographic Records noch präzisiert werden. Diese begriffliche Abklärung ergibt sich in vielen Fällen aus der Darstellung der bibliographischen Information als Prozess. Als ein Beispiel wurde in FRBRoo — eine Anwendung schon die Klasse Work mit ihren präzisierenden Unterklassen dargestellt. Insbesondere wurde mit der Klasse F18 Serial Work eine Möglichkeit geschaffen, die Unklarheiten zu Serials, also den fortlaufenden Sammelwerken, in den FRBR zu beseitigen. In den FRBR ist eindeutig beschrieben, dass eine Manifestation in dem Sinn abgeschlossen sein muss, dass man ein Exemplar kaufen und ins Regal stellen kann. Bei fortlaufenden Sammelwerken ist das nicht möglich, solange es weitere Bände –- beispielsweise in Form von Jahrgängen und Heften -– gibt. In FRBRoo heißt es dazu:

This class comprises works that are, or have been, planned to result in sequences of manifestations with common features. Whereas a work can acquire new members over the time it evolves Expressions and Manifestations are identified with a certain state achieved at a particular point in time. Therefore there is in general no single expression or manifestation representing a complete serial work, unless the serial work is ended. […] Serial Works may or may not have a plan for an overall expression.

Es ist zu beachten, dass FRBRoo keine Unterscheidung zwischen Serien und Reihen bzw. Periodika macht, da der Unterschied „nur“ in der Art der Erscheinungsweise liegt und dies über andere Mechanismen modellierbar ist. Somit ergeben sich zwei Fälle:

  • fortlaufende Sammelwerke mit eingebetteten mehrbändigen Werken und
  • fortlaufende Sammelwerke ohne eingebettete mehrbändige Werke

Zu Ersteren zählen beispielsweise Zeitschriften mit Jahrgangzählung.

Fortlaufende Sammelwerke mit eingebetteten mehrbändigen Werken

Nachdem, was in dieser Beitragsreihe bisher gezeigt wurde, lässt sich ein mehrbändiges Werk innerhalb eines fortlaufenden Sammelwerks als F15 Complex Work beschreiben. Dass dies auch im Falle von Periodika gilt, in dem die Jahrgänge in der Regel Fortsetzungswerke sind, wird auch durch folgendes Zitat aus der Definition zu F15 Complex Work deutlich: „One part may not be finished when another is already revised.“
Die Komponente des unbestimmten Endes eines fortlaufenden Sammelwerks entsteht also bei der Einbindung der Complex Works der Mehrbänder in das Serial Work. In der folgenden Abbildung wird das F15 Complex Work zum Publikationsprozess dann noch zusätzlich um die Struktur des F18 Serial Work erweitert.

HGB_F18

Fortlaufende Sammelwerke ohne eingebettete mehrbändige Werke

Die letzte Abbildung zeigt auch, wie sich dieser Fall aus den vorherigen Modellen herleiten lässt. Da es sich hier um Einzelwerke und Sammelwerke handelt, die in einer Reihe erschienen sind, werden die Individual Works und somit auch die Aggregation Works als member eines Serial Work definiert.

Beispiel für fortlaufende Sammelwerke

Und nun?

In dieser Beitragsreihe habe ich gezeigt, dass man mittels FRBRoo bibliographische Daten als Linked Data darstellen kann. Ich hoffe, dass ich ebenfalls zeigen konnte, dass man vor den FRBRoo keine Angst haben muss 😉

Eines sollte man bei der Betrachtung solcher Modelle immer im Hinterkopf haben: Bibliographische Metadaten müssen nicht in dieser Form katalogisiert werden, sie werden lediglich so gespeichert!
Wir müssen uns im Bibliothekswesen von dem Gedanken verabschieden, dass wir die Datenfelder in den Formaten als MAB/MARC-Feld-Wert-Paare und deren Unterfeldern erfassen müssen, wie es in den einschlägigen integrierten Bibliothekssystemen derzeit der Fall ist.
Es sollten vielmehr Erfassungssysteme entwickelt werden, die eine semantisch reichhaltige Verknüpfung zu Daten aus der Linked Open Data Cloud zulassen und die wenigen noch übrig bleibenden Zeichenketten und Zahlen in einfachen Formularen erfassen. Die semantischen Netze der Datenmodelle, wie sie die FRBRoo darstellen, werden im Hintergrund und vom (bibliothekarischen) Nutzer verborgen angelegt.

Beispiele: FRBRoo und fortlaufende Sammelwerke

Beispiele für FRBRoo und fortlaufende Sammelwerke

Nachrichten für Dokumentation in Technik und Wissenschaft, Wirtschaft und Verwaltung. (Hauptsachtitel)

  • Nachrichten für Dokumentation : nfd ; Zeitschrift für Informationswissenschaft und -praxis ; Mitteilungsblatt des Normenausschusses Bibliotheks- und Dokumentationswesen im DIN, Deutsches Institut für Normung e.V., des VDD – Berufsverband Information, Dokumentation, Kommunikation e.V. und der Arbeitsgemeinschaft der Spezialbibliotheken (ASpB) / hrsg. von d. Deutschen Gesellschaft für Dokumentation e.V., Frankfurt am Main / Deutsche Gesellschaft für Dokumentation, Informationszentrum für Informationswissenschaft und -praxis .
    1.1950 – 48.1997,4. : Darmstadt : Hoppenstedt (Frankfurt, M. : Dt. Ges. für Dokumentation [1950-1973], Pullach bei München : Verl. Dokumentation [1974-1977], München [u.a.] : Saur [1978-1986], Weinheim : VCH [1987-1991]).
    ZDB-ID: 206965-9
  • Nfd : Information – Wissenschaft und Praxis ; Mitteilungsblatt des Normenausschusses Bibliotheks- und Dokumentationswesen im DIN, Deutsches Institut für Normung e.V. und der Arbeitsgemeinschaft der Spezialbibliotheken (ASpB) / hrsg. von der Deutschen Gesellschaft für Informationswissenschaft und Informationspraxis e.V. /
    Deutsche Gesellschaft für Informationswissenschaft und Informationspraxis.
    48.1997,5 – 52.2001 : Frankfurt, M. : Gesellschaft (Heidelberg : Heidelberger Verl.-Anst. u. Dr. [1997,5]).
    ZDB-ID: 1399316-1.

Neben zahlreichen Verlagswechseln, kommen bei diesem fortlaufenden Sammelwerk mit eingebetteten mehrbändigen Werken noch einige Titeländerungen und Änderungen bei der herausgebenden Körperschaft hinzu. In der folgenden Abbildungen werden daher nur ein paar Änderungen verdeutlicht.

Beispiel Serial Work für eine Zeitschrift

Zu beachten ist, dass die Änderungen sämtlichst auf der Ebene der Zeitschriftenhefte erfasst wird, da die Zeitschrift ansich (das F18 Serial Work) keine eigene Manifestation besitzt.
Die Erfassung der Titeländerungen für die Zeitschrift können zusätzlich über Teilereignisse des F30 Publication Event des zugehörigen Heftes abgebildet werden. Diese Teilereignisse sind mittels CRM als E13 Attribute Assignment darstellbar und bilden den Prozess der Titelvergabe für das F18 Serial Work ab. Mit Hilfe von Vorgänger- und Nachfolgerrelationen der Ereignisse ist es dann möglich, dem fortlaufenden Sammelwerk den aktuellen Titel zuzuweisen („E13 Attribute Assignment enthält keine Eigenschft P120 occours before„).

Beispiel Serial Work Zeitschrift Titeländerung

Mögliche RDF-Darstellung

siehe / see: example5.ttl

Sammelwerke, Sammlungen, mehrbändig begrenzte Werke und FRBRoo

Im Beitrag FRBRoo — Eine prozessorientierte Sicht auf bibliographische Informationen habe ich gezeigt, wie sich Einzelwerke mittels FRBRoo darstellen lassen. Im folgenden wird das Modell auf Sammelwerke, Sammlungen und mehrbändig begrenzte Werke ausgeweitet.

Ein Sammelwerk oder eine Sammlung zeichnet sich dadurch aus, dass es Expressions anderer Werke in sich vereint oder anders ausgedrückt aggregiert. Für diese Werke gibt es in den FRBRoo die Entität F17 Aggregation Work, welches die Eigenschaften des F14 Individual Work und des F16 Container Work in sich vereint:

This class comprises works whose essence is the selection and/or ar-rangement of expressions of one or more other works. This does not make the contents of the aggregated expressions part of this work, but only part of the resulting expression. F17 Aggregation Work may include additional original parts.

An diesem Publikationstyp sind somit mehrere Werke und deren Realisierungen beteiligt: zum einen sind dies die Werke der Beiträge, zum anderen ist es das Sammelwerk an sich. Daraus folgt auch, dass es einige zu betrachtende Prozesse gibt.

Die Schöpfungsprozesse sind zunächst mal dem des Einzelwerks sehr ähnlich (bei den Beiträgen handelt es sich um Einzelwerke, beim Sammelwerk handelt es sich um ein F17 Aggregation Work, welches von F14 Individual Work abgeleitet ist). Allerdings kommt hinzu, dass die aus den Beiträgen entstandenen Expressions neben ihrer Eigenschaft sich selbst zu enthalten (F22 Self-contained Expression) auch Fragmente (F23 Expression Fragment) einer übergeordneten Expression, der des Sammelwerks, sind. Die nächste Abbildung stellt dies graphisch dar. Somit ist eine Expression/span> eines Beitrags gleichzeitig Instanz von F22 und F23.

Die soeben beschriebene Fragmentierung gilt auch im Publikationsprozess. So erhält jede Expression eines Beitrags eine eigene F24 Publication Expression. Somit gilt für die Expressions im Publikationsprozess, dass sie gleichzeitig Instanzen von F24 und F23 sind.

Sammelwerk

Beispiel

Mehrbändig begrenzte Werke

Bei der Abbildung von mehrbändig begrenzten Werken wird es schon etwas komplexer. Es gibt hier zwei zu unterscheidende Fälle: mehrbändiges Werk im Schöpfungsprozess (bibliographische Einheiten) und mehrbändiges Werk im Publikationsprozess (buchbinderische Einheiten).
Bei der Mehrbändigkeit im Schöpfungsprozess findet die Definition der Entität F15 Complex Work Verwendung:

This class comprises works that have more than one work as members. The members of a Complex Work may constitute components of the overall concept or be alternatives to other members of the work. […] The member relationship of Work is based on the conceptual relationship, and should not be confused with the internal structural parts of an individual expression.

Die Mehrbändigkeit bezieht sich in diesem Fall auf die inhaltliche Ebene. Somit ergibt sich aus dieser Definition direkt die Unterscheidung zur Mehrbändigkeit im Publikationsprozess, bei der sich die Mehrbändigkeit rein praktisch begründet. In letzterem Fall wird die „einbändige“ Expression des Verfassers in mehrere Manifestations aufgeteilt.
Die folgende Abbildung stellt ein im Publikationsprozess entstehendes mehrbändiges Werk dar, lässt dabei aber den Aspekt des Produktionsprozesses weitestgehend außen vor, da er sich nicht von dem des Kernmodells unterscheidet. Das vom Verfasser initiierte Werk wird im Vorfeld des Publikationsprozesses in mehrere Fragmente zerlegt (F23 Expression Fragment). Diese werden dann jeweils in den Publikationsprozess geleitet und werden somit zu Publication Works. Diese wiederum ergeben gemeinsam ein komplexes Werk im Sinne der FRBRoo-Definition, da hier eine gemeinsame inhaltliche Konzeption –- in der Regel durch den Verlag -– zugrunde liegt. Somit sind die den Werken zugrundeliegenden Instanzen der Work Conceptions unterschiedliche Ereignisse. (Im Abschnitt „Events in FRBROO: How Each Group 1 Entity Comes into Being“ des Beitrags „A Strange Model Named FRBROO. In: Cataloging & Classification Quarterly: Routledge 2012.“ stellt Patrick Le Boeuf dar, was genau unter der Work Conception zu verstehen ist.)

Mehrbändig begrenztes Werk im Publikationsprozess

Die entstandenen Complex Works erhalten jeweils einen eigenen Expression-Zweig. Dieser existiert, sobald das Werk vollständig ist, und da es sich hier um mehrbändig begrenzte Werke handelt, ist bereits von der Vollständigkeit auszugehen. Die Expression Creation-Ereignisse der einzelnen Bände sind somit Teilereignisse der Expression Creation des F15 Complex Work (P9 consists of) und die Expressions der Bände sind Teile der Expression des Complex Work. Bei letzterem ist die Teil-Beziehung nicht mit der Enthaltenseinsbeziehung bei Wiederverwendung einer Expression zu verwechseln. In den FRBRoo heißt es zur Relation R5 has component:

This property associates an F2 Expression X with a structural compo-nent Y that conveys in itself the complete concept of a work that is member of (R10) the overall work realized by X. It does not cover the relationship that exists between pre-existing expressions that are re-used in a new, larger expression and that new, larger expression. Such a relationship is modeled by R14 incorporates.

Beispiel für ein im Publikationsprozess mehrbändig begrenztes Werk

In der nächsten Abbildung ist ein im Schöpfungsprozess entstehendes mehrbändiges Werk dargestellt. Im Unterschied zum vorigen Fall findet hier die Zerlegung schon auf Werksebene statt, da der Verfasser schon bei der Konzeption einen Mehrbänder im Sinn hat. Diese Bände werden als Individual Works modelliert und durch jeweils eigene Expressions realisiert. Diese wiederum gehen dann getrennt voneinander in den Publikationsprozess. Wie auch im vorigen Fall, bilden die resultierenden Publication Works eine Einheit in Form eines Complex Work. Für den Fall, dass alle Bände von gleicher Auflage und vom gleichen Verfasser sind, so existiert auch hier eine eigene Realisierung bzw. Expression des Complex Work.

Mehrbändig begrenztes Werk im Schöpfungsprozess

Beispiel für ein im Schöpfungsprozess mehrbändig begrenztes Werk

Im nächsten Post „FRBRoo und fortlaufende Sammelwerke“ werden die bisherigen Elemente zusammengefügt und somit ein Modell für die fortlaufenden Sammelwerke präsentiert.

Beispiele: FRBRoo für mehrbändig begrenzte Werke / Examples: FRBRoo for Multivolume Works

Beispiele für / Examples for: Sammelwerke, Sammlungen, mehrbändig begrenzte Werke und FRBRoo

Grundlagen der praktischen Information und Dokumentation : ein Handbuch zur Einführung in die fachliche Informationsarbeit / Buder, Marianne ; Laisiepen, Klaus.
München [u.a.]: Saur, 1990.
3., völlig neu gefasste Ausg.
ISBN: 3-598-21253-4

Graphische Darstellung / graphical representation

Beispiel eines mehrbändig begrenzten Werkes im Publikationsprozess

Mögliche RDF-Darstellung / representation in RDF

siehe / see: example3.ttl


Analysis / Forster, Otto.
Bd. 1: Differential- und Integralrechnung einer Veränderlichen.
Braunschweig [u.a.]: Vieweg, 2008. 9., überarb. Aufl.
Bd. 2: Differentialrechnung im R n, gewöhnliche Differentialgleichungen.
Braunschweig [u.a.]: Vieweg, 2008. 8., aktualisierte Aufl.
Bd. 3: Integralrechnung im R n mit Anwendungen.
Braunschweig [u.a.]: Vieweg, 2009. 5., aktualisierte Aufl.

Graphische Darstellung / graphical representation

Beispiel eines mehrbändig begrenzten Werkes im Schöpfungsprozess

Mögliche RDF-Darstellung / representation in RDF

siehe / see: example4.ttl

Beispiel: FRBRoo für Sammelwerke und Sammlungen / Example: FRBRoo for Aggregation Works

Beispiel für / Example for: Sammelwerke, Sammlungen, mehrbändig begrenzte Werke und FRBRoo

Commercial Interchanges Between Greeks and Natives / Graham, Alexander John
In: Collected papers on Greek colonization / Graham, Alexander John (Hrsg.)
Leiden, Boston, Köln : Brill, 2001.

Graphische Darstellung / graphical representation

Sammelwerk Beispiel

Mögliche RDF-Darstellung / representation in RDF

siehe / see: example2.ttl

FRBRoo — Eine prozessorientierte Sicht auf bibliographische Informationen

Nachdem ich in FRBRoo — eine Anwendung meine Motivation in Bezug auf FRBRoo erläutert habe, werde ich im Folgenden die Publikationsformen mithilfe der FRBRoo dargestellen. Dabei stützt sich die Modellierung vor allem auf die Ereigniszentriertheit des CRM, wodurch die Schöpfungs-, Publikations- und Produktionsprozesse transparenter werden.

Für den Fall, dass der geneigte Leser die Definitionen der Publikationsformen nicht mehr so ganz auf dem Schirm hat, stelle ich sie nochmal kurz unter Verwendung des „Bibliothekrischen Grundwissens“ von Ganter/Hacker vor.

  • Einzelwerk
    Ein Einzelwerk ist eine in sich geistige abgeschlossene Schöpfung, die zur zusammenhängenden Veröffentlichung vorgesehen ist und in einem oder mehreren Teilen erscheint.
  • Sammlung
    Als Sammlung wird eine Veröffentlichung bezeichnet, in der zwei oder mehr Einzelwerke desselben Verfassers vereinigt sind.
  • Sammelwerk
    Unter Sammelwerk versteht man ein Buch mit mindestens zwei Einzelwerken von zwei oder mehr Verfassern.
  • Fortsetzungswerk
    Fortsetzungswerk nennt man eine mehrbändige Publikation, bei der die einzelnen Bände oder Teile nacheinander in zeitlichen Abständen
  • Fortlaufende Sammelwerke
    Wenn in mehreren Teilen erscheinende Sammelwerke keinen von vornhinein geplanten Abschluss haben, sondern […] ohne Begrenzung der Band- oder Heftzahl erscheinen, nennt man sie fortlaufende Sammelwerke. Dazu zählen Schriftenreihen (Serien) und Periodika (Zeitungen, Zeitschriften, zeitschriftenartige Reihen).

Die zentrale Rolle beim Mapping mit den FRBRoo stellt die Verfeinerung des Werk-Begriffs der FRBR dar.
Die Ausführungen in den originalen FRBR zu den Gruppe-1-Entitäten lassen in einigen Fällen verschiedene Interpretationen zu, die in Teilen zu logischen Inkonsistenzen führen. Insbesondere die Entität Work deckt mehrere Szenarien ab, die in der Realität verschiedene Eigenschaften haben. Die FRBRoo greifen diese Ungenauigkeit auf und definieren das Work als Superklasse und verfeinern diese dann durch Work-Begriffe, welche die verschiedenen Szenarien modellieren können.

Work-Hierarchie der FRBRoo

So entsteht beispielsweise eine Entität Serial Work, die zum einen den intellektuellen Anteil des Verlags berücksichtigt (Publication Work) und zum anderen eine Umgebung für die Aggregation anderer Werke bildet (Complex Work). Dabei ist die soeben genannte Aggregation nicht mit der Aggregation bei Sammelwerken zu verwechseln. Letztere findet auf der Ebene der Expressions statt. In den FRBRoo heißt es zu Aggregation Work:

This class comprises works whose essence is the selection and/or ar-rangement of expressions of one or more other works. This does not make the contents of the aggregated expressions part of this work, but only part of the resulting expression. F17 Aggregation Work may include additional original parts.

Somit fallen hierunter die Sammelwerke und Sammlungen.

Legt man nun die Publikationstypen nach dem bibliothekarischen Standardwerk von Gantert/Hacker zugrunde, so ergibt sich für die Publikationstypen das folgende Bild. Die Abbildung enthält zwei Typen von Relationen: Unter-/Oberklassen (subClassOf) und Teil/Ganzes-Beziehungen (hasPart). Letztere stellen dabei – die insbesondere im deutschen Bibliothekswesen starken – Verknüpfungen zu Überordnungen dar.

Verknüpfungen innerhalb der Publikationsformen

Diese Abhängigkeiten lassen sich nun auf die FRBRoo-Entitäten abbilden, wobei sich Publikationsformen FRBRoo-Entitäten „teilen“. Am Beispiel des fortlaufenden Sammelwerks sind dies die Serie/Reihe und das Periodikum, welche sich das Serial Work teilen. Der formale Unterschied zwischen Serien und Periodika ist „nur“ die Beschreibung der Erscheinungsweise. Diese kann aber in einem Modell, wie es die FRBRoo sind, durch die Verwendung entsprechender Vokabulare für die Attribute der Entitäten beschrieben werden.

Abbildung der Publikationsformen auf die Work-Entitäten der FRBRoo

Einzelwerke und die Akteure der Prozesse

Das CRM und somit die FRBRoo liefern durch ihre Ereigniszentriertheit für das Modell drei wesentliche Prozesse: den Schöpfungsprozess (realisiert durch das Ereignis F28 Expression Creation), den Publikationsprozess (realisiert durch das Ereignis F30 Publication Event) und den Produktionsprozess (realisiert durch das Ereignis F32 Carrier Production Event).
Die Beschreibung des Publikationstyps Einzelwerk stellt in einem gewissen Sinne ein Kernmodell dar. So werden darin die grundsätzliche Unterscheidung und die Zusammengehörigkeit der oben genannten Prozesse sichtbar. Die in diesen Prozessen verwendeten Entitäten und Relationen werden bei sämtlichen Publikationstypen wieder verwendet und den Gegebenheiten angepasst. Der Übersichtlichkeit halber wird das Modell in zwei Teilen präsentiert: dem Modell für die materiellen Konzepte und die Ereignisse sowie dem Modell der Akteure.

Einzelwerke

Die Linien der Schöpfungs- und Publikationsprozesse verbinden sich auf der Ebene der Expressions. Hier wird der Tatsache Rechnung getragen, dass der Verlag durch das Hinzufügen seines Layouts und sonstiger, ergänzender Teile die Expression und somit die Realisierung des Schöpfers anreichert. Diese erweiterte Expression wird dann in den Produktionsprozess weitergeleitet.

Aus der Sicht eines Bibliothekskatalogs sind in der Regel zum Schöpfungsprozess des Werks wenige bis keine Informationen bekannt. Die formalen Beschreibungen der Werksebene werden im Bibliothekskontext entsprechend auf der Seite des Publikationsprozesses abgelegt, d.h. insbesondere, dass der Titel, so wie er bei der formalen Erschließung erfasst wird, als Attribut zum F19 Publication Work gehört. Anders ist das bei der Zuordnung der Akteure des Schöpfungsprozesses. Hier ist bei der formalen Erschließung bekannt, dass die angegebenen Personen oder Körperschaften an der Realisierung der Expression mitgewirkt haben.

Die Akteure werden in dem vorliegenden Modell zum einen als Ausführende direkt an die Ereignisse angebunden (unter Verwendung der Relation P14 carried out by des CRM), zum anderen werden die Rollen der Akteure mithilfe des RDA-Vokabulars modelliert. (Das CRM liefert selber auch eine Möglichkeit, den Ausführenden eines Ereignisses eine Rolle zuzuordnen. Und zwar sieht das CRM eine Relation P14.1 in the role of der Relation P14 carried out by vor. Dieses Konstrukt ist in dieser Form aber nicht RDF-konform und müsste durch die Modellierung eines sogenannten Blank-Nodes aufgelöst werden. Da die Verwendung von Blank-Nodes in der Praxis nicht unbedingt empfohlen wird (Vgl. z.B. Heath, Tom u. Christian Bizer: Linked Data. Evolving the web into a global data space. 1. Aufl. San Rafael, Calif: Morgan & Claypool 2011, 2.4.1) und das Bibliothekswesen mit den RDA eine geeignete Alternative hat, wird diese hier auch verwendet.)

Akteure

Die Abbildung zeigt die Verwendung eines weiteren Modells, den FRBRentitesRDA. Hierbei handelt es sich um die Definition der FRBR-Entitäten aus dem RDA-Modell. An dieser Stelle soll nun die Verbindung der Modelle genauer aufgezeigt werden.
Die FRBRoo greifen wie oben erwähnt die Schwachstellen der FRBR auf und versuchen diese zu beheben. Dabei verlassen sie aber nie das Grundvokabular der FRBR-Entitäten. So bleiben die Entitäten Work, Expression, Manifestation und Item in FRBRoo erhalten und bekommen nur die CRM-typische Nummer verliehen. Auch die RDA basieren auf den Konzepten der FRBR. Somit sind die vier Entitäten der FRBR-Gruppe 1 in allen drei Modellen äquivalent bzw. im Fall von F3 Manifestation-Product Type und F4 Manifestation Singleton in FRBRoo abgeleitet. Diese Feststellung ist insofern wichtig, dass es nur dann möglich ist, Relationen und Attribute aus verschiedenen Modellen und Ontologien zu benutzen, wenn die Entitäten in der beschriebenen Weise zusammenpassen.

In der hier vorgestellten Modellierung werden die Entitäten der FRBRoo mit denen der FRBRentitiesRDA „gematcht“, um nicht sämtliche Metadaten zu den Instanzen als CRM oder FRBRoo-Tripel zu beschreiben, was den Graph in seiner Größe förmlich explodieren ließe. Der Vorteil hierbei ist, dass ab einer bestimmten Tiefe des Graphen nur noch bereits bekannte und hoffentlich standardisierte Metadaten verwendet werden.
Verwendet man nur das CRM, so müssen für Aussagen sehr viele Tripel erzeugt werden, bis die Semantik klar ausgedrückt wird, wodurch sehr große Graphen entstehen. Um diese Graphen kleiner zu halten, wird mittels Ontology Alignement ein Mapping zu Modellen erzeugt, die für die gleiche Aussagekraft kürzere Wege erlauben. So entsteht ein durch das CRM zusammengehaltener Graph, dessen Knoten durch fachspezifische Ontologien beschreiben werden.
Auch Mazurek, Cezary et al. berichten in ihrem Beitrag From MARC21 and Dublin Core, through CIDOC CRM. First Tenuous Steps towards Representing Library Data in FRBRoo. von dieser Problematik. Sie zeigen in ihrem Beitrag an einem Beispiel, wie kleinteilig diese Art der Modellierung wäre.

Das bisher beschriebene Modell soll durch ein Beispiel verdeutlicht werden.

In den nächsten Beiträgen zeige ich dann, wie das bei Sammelwerken, Sammlungen und den zugehörigen Beitragen sowie bei mehrbändig begrenzten Werken aussieht.

Weiterlesen: