| Inhalt |
|---|
Titel
Inhalt | RDF-Element | Bemerkung |
Haupttitel | ||
Titelzusätze |
| |
Zählung eines unselbständigen Teils | Titel des unselbständigen Teils_Zählung des unselbständigen Teils | |
Unselbständiger Teil | Titel des unselbständigen Teils_Zählung des unselbständigen Teils | |
|
| |
Kurztitel |
| |
Paralleltitel |
|
...
Haben sich die Veröffentlichungsangaben über die Zeit verändert (z.B. bei Zeitschriften), sollten auf die im Folgenden empfohlene Art nur die jeweils aktuellen Angaben ausgegeben werden.
Identifier
Vor allem im Bereich der Identifier sind Literale wenig nützlich. Ziel ist es, nur noch auf URIs zu verweisen und auf Literale gänzlich zu verzichten .Derzeit bestehen größtenteils noch keine zufriedenstellenden Lösungen, dies zu realisieren.
Wichtige und verbreitete Identifier, für die bereits URIs oder spezielle Properties existieren, sollten verwendet werden (siehe folgende Tabelle); alle weiteren werden nicht ins Kernelementset aufgenommen. Identifier, für die keine Properties existieren, sollten mit dc:identifer + datatype modelliert werden.
Identifizierung
Der Identifizierung einer Ressource mittels eines, von einem vertrauenswürdigen Bereitsteller unterhaltenen, URIs ist der Literalangabe eines Identifiers vorzuziehen, da dort ggf. weitere beschreibende Daten zu der Ressource bezogen werden können. Zur Verdeutlichung: ein URN sollte statt als Literal besser zum dereferenzierbaren URI ergänzt werden (siehe Tabelle unten). Wenn diese Möglichkeit nicht bestelt, sollte die Property dcterms:identifier verwendet werden, um den Identifier als Literal zu transportieren. Ein Datentyp kann genutzt werden, um die Art des Identifiers auszuzeichnen.!!Die Verwendung von dcterms:identifier ist in diesem Zusammenhang irgendwie irreführend. Wir sagen im Text, dass nur noch URIs verwendet werden sollen und auf Literale gänzlich verzichtet werden soll. Andererseits ist die Range von dcterms:identifier aber rdfs:Literal. Das passt dann irgendwie nicht zusammen. Ich schlage daher vor, entweder bei dc:identifier zu bleiben oder den Text zu ändern.
!!
Zudem empfehlen wir Institutionen, die selbst lokale oder regionale Identifier herausgeben, eine entsprechende Property als Subproperty von dc dcterms:identifier zu prägen. Beispiel: die Property http://purl.org/lobid/lv#hbzID für den regionalen Identifier der hbz-Verbunddatenbank.
...
Die in culturegraph.org nachgewiesenen Titeldaten sollten mittels owl:sameAs mit lokalen Datensätzen der Verbundsysteme relationiert werden. Da der culturegraph-Datensatz aus dem Datensatz der jeweiligen Verbundsysteme generiert wird, kann davon ausgegangen werden, dass der Verbund-Datensatz und der daraus generierte culturegraph-Datensatz dasselbe Objekt beschreiben. Die in culturegraph nachgewiesenen Titel beinhalten wiederum weitere Verweise - beispielsweise Verweise auf die berechneten Bündel, deren Mitglied sie sind. Auf diese Weise entsteht eine flexible Verweiskette. Diese Kette kann zu einem späteren Zeitpunkt für vereinbarte stabilisierte Verweise (wie z.B. stabile Verweise auf Werke oder Manifestationen) durch direkte Referenzen aus den lokalen Datensätzen ersetzt werden. Solche Vereinbarungen werden ggf. Gegenstand einer späteren Version dieser Empfehlung sein.
Da die Datenlieferungen in zeitlichen Abständen an culturegraph erfolgen, ist es unter Umständen möglich, dass Datensätze neueren Datums noch nicht über culturegraph.org nachgewiesen werden und sich somit die Referenz zeitweilig nicht auflöst.
Das MARC-Feld 001 (NR) beinhaltet den Identifier der publizierenden Institution. Entsprechend wird hier das Kürzel des publizierenden Verbundsystems für die Generierung des culturegraph-Verweises verwendet.
Die Verbundkürzel setzen sich für die derzeit in culturegraph nachgewiesenen Verbundbestände wie folgt zusammen (Stand Mai 2013):
- BSZ (Südwestdeutscher Bibliotheksverbund bzw. das Bibliotheksservicezentrum),
- BVB (Bayerischer Bibliotheksverbund),
- DNB (Deutsche Nationalbibliothek),
- GBV (Gemeinsamer Bibliotheksverbund),
- HBZ (Hochschulbibliothekszentrum Nordrhein-Westfalen),
- HEB (Hessisches BibliotheksInformationsSystem),
- OBV (Österreichischer Bibliotheksverbund),
- ZDB (Zeitschriftendatenbank)
Inhalt | RDF-Element | Objekttyp | Bemerkung | ||||||||||||||||||||||||||||||||||||||||||
Kontrollnummer / Identifikationsnummer des Datensatzes | URI | <owlWert: sameAs rdf:resource=“
| |||||||||||||||||||||||||||||||||||||||||||
(<ISIL des Verbundes>)<ID des Datensatzes im Verbundsystem> |
|
| |||||||||||||||||||||||||||||||||||||||||||
|
| <owl:sameAs rdf:resource=“
|
|
| <owl:sameAs rdf:resource=“
| owl:sameAs |
| ||||||||||||||||||||||||||||||||||||||
Digital Object Identifier (DOI) | umbel:isLike | URI | <umbel:isLike rdf:resource="Wert: | ||||||||||||||||||||||||||||||||||||||||||
| URN | umbel:isLike | URI | Wert: <umbel:isLike rdf:resource="http://nbn-resolving.de/<urn>"/<urn> | ||||||||||||||||||||||||||||||||||||||||||
International Standard Serial Number | Literal |
| Optionale Alternative: | EISSN | bibo:eissn für EISSN | ||||||||||||||||||||||||||||||||||||||||
ISSN | Für ISSN | ||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||
Library of Congress Control Number, LOC Nummer | Literal |
| |||||||||||||||||||||||||||||||||||||||||||
OCLC-Nummer | Literal |
| |||||||||||||||||||||||||||||||||||||||||||
International Standard Book Number ISBN | Literal |
|
Inhaltstyp, Medientyp, Datenträgertyp
...
Inhalt | RDF-Element | Objekttyp | Bemerkung |
Inhaltstyp | rdau:P60049 | URI | Werte aus RDA Content Type Value Vocabulary
Auch spezifischere Werte sind möglich, sollten aber auch dann kontrolliert und mittels URI identifizierbar sein. |
| Medientyp | rdau:P60050 | URI | Werte aus RDA Media Type Value Vocabulary
Beachte: der Datenträgertyp ist eine Spezifizierung des Medientyps. Darüber hinaus sind weitere spezifischere Werte möglich, sollten aber auch dann kontrolliert und mittels URI identifizierbar sein. |
| Datenträgertyp | rdau:P60048 | URI | Werte aus RDA Carrier Type Value Vocabulary
Auch spezifischere Werte sind möglich, sollten aber auch dann kontrolliert und mittels URI identifizierbar sein. |
...
Inhalt | RDF-Element | Objekttyp | Bemerkung |
Audiovisuelles Material
| rdf:type | URI |
|
| Kartenmaterial | rdf:type | URI | bibo:Map |
| Hochschulschrift | rdf:type | URI | bibo:Thesis |
Mikroform
| dcterms:medium | URI | rdacarrierrdamt:10201002 (Microform Carrier)
|
| Onlineressource | dcterms:medium | URI | rdacarrier:1018 (online resource) Note: hier wird der RDA carrier type angegeben, damit eine Unterscheidung zwischen Online und Elektronisch ( = auf Datenträger, aber nicht "Online-Ressource) möglich ist |
| Elektronische Ressource | dcterms:medium | URI | rdacarrierrdamt:10101003 (computer) Note: mit rdacarrierrdamt:10101003 werden alle elektronischen Ressourcen gekennzeichnet, ausgenommen sind hier die Online-Ressourcen, s. a. Note zu rdacarrier:1018) |
| Multimediamaterial | dcterms:medium | URI | isbdmediatype:T1008 (multiple media) |
| keine explizite Angabe eines Mediums | dcterms:medium | URI | |
| Blindenschrift | rdf:type | URI | "lib:BrailleBook" |
Erscheinungsweise
Dieses Informationselement eignet sich perspektivisch, um ebenfalls von den RDA-Elementen (Property rdau:P60051, RDA Mode of Issuance Value Vocabulary) vollständig repräsentiert zu werden. Derzeit wird das RDA Mode of Issuance Vocabulary allerdings als nicht umfangreich genug angesehen, um die in Version 1 dieser Empfehlungen etablierte Granularität (zunächst integriert in der Rubrik "Medientyp") abzulösen.
Artikel | rdf:type | |
| Ausgabe / Heft Zeitschrift | rdf:type | "bibo:ArticleIssue |
| Zeitschrift | rdf:type | ""bibo:Periodical" |
| Zeitung | rdf:type | bibobibo:Newspaper |
| Sammlung | rdf:type | "bibo:Collection" |
| Serie | rdf:type | "bibo:Series" |
| Monografie | rdf:type | bibobibo:Book |
| Mehrbändiges Werk | rdf:type | bibobibo:MultivolumeBook |
| keine Angabe einer besonderen Erscheinungsweise | rdf:type |
Relationen
Wann immer die Properties der DCMI Metadata Terms die Art der Relation aussagekräftig genug beschreiben, sollten sie verwendet werden. Werden die Relationen spezifischer erfasst, sollte das - auch über die untenstehende Tabelle hinaus - mittels RDA Unconstrained Properties ausgedrückt werden. ToDo Im MARC 21-RDF-Mapping ist eine Mapping der deutschen RDA-Relationsbezeichnungen auf die RDA Unconstrained Properties enthalten.
...