[dini-ag-kim-lld] Re: Repräsentation von Bibliotheksstrukturen als LinkedData

Adrian Pohl pohl at hbz-nrw.de
Mon Oct 24 10:04:35 CEST 2011


Hallo,

mir ist gerade noch ein großes Versäumnis aufgefallen, was erklären
könnte, dass Jakob die durchaus wichtige Klasse dcmitype:Collection
in seiner letzten Mail gar nicht angesprochen hat. Offensichtlich habe
ich vergessen, sie in meiner Arbeit auch nur einmal zu nennen - weder
weise ich im Fließtext drauf hin noch in den Listing à la 

<> rdf:type dcmitype:Collection. 

Blöde Sache. :-( Jedenfalls geht es um diese Klasse, wenn ich von
Sammlungen spreche...

Ciao
Adrian

 >>>"Adrian Pohl" <pohl at hbz-nrw.de> schrieb am 24.10.2011 um 9:41:
> Hallo,
> 
> ich habe gerade nicht viel Zeit, deshalb nur ein paar kurze
> Anmerkungen.
> 
>  >>>Jakob Voss <jakob.voss at gbv.de> schrieb am 21.10.2011 um 15:51:
>> Hallo,
>> 
>> Die Frage nach Holding/Item-Informationen wird in einem Thread auf
>> public-lld at w3.org fortgesetzt. Adrian hat dort auch noch mal auf
> seine 
>> Masterarbeit "Zur Konzeption und Entwicklung eines RDF-Vokabulars
für
> 
>> die Beschreibung bibliothekarischer Organisationen, ihrer
Sammlungen
> und 
>> Dienstleistungenüber" (lobid.org) hingewiesen:
>> 
>> http://hdl.handle.net/10760/16175
> 
> Danke für den Hinweis auf meine Arbeit.
> 
>> Adrian schlägt dabei u.A. Klassen und Relationen aus der W3C 
>> Organization Ontology und aus der GoodRelations Ontology vor:
>> 
>> @prefix org: <http://www.w3.org/ns/org#> .
>> @prefix gr: <http://purl.org/goodrelations/v1#> .
>> 
>> Zur Dokumentation dieser Ontologien siehe:
>> 
>> http://www.epimorphics.com/public/vocabulary/org.html
>> http://www.heppnetz.de/projects/goodrelations/
>> 
>> 
>> Hier drei Beispiele aus der Arbeit:
>> 
>> 
>> <http://lobid.org/organisation/DE-605> a foaf:Organization .
>> 
>> <http://lobid.org/organisation/DE-38>  a org:OrganizationalUnit ;
>>    gr:hasPOS _:Anmeldung ;
>>    gr:hasPOS _:Auskunft ;
>>    gr:hasPOS _:Sofrotausleihe ;
>>    gr:hasPOS _:Rückgabe ;
>>    gr:hasPOS _:Lesesaal ;
>>    gr:hasPOS _:Freihandmagazin .
>> 
>> <http://lobid.org/organisation/DE-380>
>>    a gr:BusinessEntity ;
>>    a org:FormalOrganization ;
>>    org:hasUnit <http://lobid.org/organisation/DE-380-01> ;
>>    org:hasUnit <http://lobid.org/organisation/DE-380-02> ;
>>    org:hasPrimarySite <http://lobid.org/site/DE-380-01> ;
>>    org:hasSite <http://lobid.org/site/DE-380-02> ;
>>    org:hasSuborganization <http://lobid.org/organisation/DE-Kn125>
.
>> 
>> 
>> Ich finde diese Vielzahl von Organisationstypen und Beziehungen
noch
> 
>> etwas unübersichtlich. Soweit ich es überblicken kann, werden
> folgende 
>> Klassen verwendet - die Unter/Überklassen.Beziehungen habe ich aus
> der 
>> Dokumentation der jeweiligen Ontologien:
>> 
>> 
>> org:Organization
>>    owl:equivalentClass foaf:Organization ,
>>    rdfs:subClassOf foaf:Agent .
>> 
>> org:FormalOrganization
>>    rdfs:subClassOf org:Organization
>> 
>> gr:BusinessEntity
>>    rdfs:subClassOf org:FormalOrganization .
> 
> Es fehlt noch org:OrganizationalUnit. Diese ist als rechtlich
> uneigenständige Einheit eine Einheit einer org:FormalOrganization.
> 
>> org:Site (ohne Bezug zu anderen Klassen)
>> 
>> gr:Location (ohne Bezug zu anderen Klassen, müsste aber i.d.R. 
>> Unterklasse von geo:SpatialThing sein).
>> 
>> Außerdem gilt
>> 
>> org:hasUnit rdfs:subPropertyOf org:hasSuborganization (welches 
>> eigentlich subProperty von dcterms:hasPart sein sollte).
>> 
>> 
>> Ich befürchte, dass die Unterscheidung von diesen Organisations-
und
> 
>> Standort-Arten in der Praxis schwierig fällt und sehr subjektiv
ist.
>> 
>> Zumindest lassen sich von gr:BusinessEntity und
> org:FormalOrganization 
>> die Klassen org:Organization (=foaf:Organization) ableiten. 
>> Hierarchische Beziehungen werden vereinfacht mit
> org:hasSuborganization 
>> ausgedrückt (oder dcterms:hasPart?).
>> 
>> 
>> foaf:Organization
>> 
>> Ich bin dabei, für Verfügbarkeitsinformationen Standorte von 
>> Bibliotheken in RDF abzubilden. Dabei fällt jedoch selbst die 
>> Unterscheidung zwischen org:Organisation, org:Site und gr:Location 
>> schwer. Beispielsweise können die Bücher einer Bibliothek u.A.
> verstreut 
>> sein über:
> 
> Eine Organisation existiert unabhängig von irhem Ort, wenn Sie etwa
> ihren Sitz wechselt muss nur ein neuer org:Site (für
Gesamtorganisation
> sowie Abteilungen, Services etc.) angegeben werden, die
> Organisations-URI und andere Informationen (Mitarbeiter,
> Abteilungszugehörigkeit, Sammlungen, Services) können gleich
> bleiben.
> 
>> 1. Teilbibliothek X
>> 2. Freihandmagazin
>> 3. Handapparat Dr. Y
>> 4. Hochschulinstitut Z
>> 
>> Was davon ist org:Organisation, was ist org:Site und was ist 
>> gr:Location? Ist die Unterscheidung überhaupt notwendig? 
> 
> 1. wäre nach diesem Ansatz Organisation, org:Site und Sammlung, 2.
und
> 3. Sammlungen, die mit einem org:Site verlinkt ist und im Besitz
einer
> org:Oganization, eine Untersammlung einer anderen Sammlugn sein kann
> etc. Ein Institut ist eine org:OrganizationalUnit einer größeren
> Organisation.
> 
> Ich hielt anfangs die Unterscheidung zwischen org:Organization und
> org:Site auch für überflüssig. Bei der RDF-Repräsentation ist sie
> allerdings nützlich, sobald man mehrere Services, Sammlungen und
> Abteilungen hat, die am selben Ort sind. Dann hängt man die
> entsprechenden Informationen an die Site-URI und kann drauf
verlinken.
> Bein kleineren Organisatione ist da sicher eine Menge Overload bei,
den
> man in der Präsentation am Ende aber gar nicht mitbekommen muss.
> 
> Aus dem 
>> Beispiel der Stadtbibliothek Köln entnehme ich dass Zweigstelle und

>> Standort zusammenfallen, eine Teilbibliothek ist also sowohl 
>> org:Organisation als auch org:Site:
>> 
>> <http://lobid.org/organisation/DE-380-02>
>>    a org:Organisation, org:Site .
> 
> Das ist nicht korrekt. Ich unterscheide zwischen
> <http://lobid.org/organisation/DE-380-02> und
> <http://lobid.org/site/DE-380-02>, wobei gilt:
> 
> <http://lobid.org/site/DE-380-02> ;
> a org:Site ;
> org:siteOf <http://lobid.org/organisation/DE-380-02> .
> 
> 
>> Beim Freihandmagazin und beim Handapparat würde man eher von einem 
>> Standort (org:Site oder gr:Location?) als von einer Organisation 
>> sprechen. 
> 
> Ich würde sie als dcmitype:Collection klassifizieren, die mit einem
> Site und einer Über-Sammlung verlinkt werden.
> 
>> Allerdings ist der Handapparat ebenso wie das 
>> Hochschulinstitut Z nicht unbedingt Teil der Bibliothek, die
Relation
> 
>> mit org:hasSuborganization wäre also u.U. unpassend.
> 
> Ja, das ist ein Problem. Idealerweise müsste die ganze Hochschule
> entsprechend in RDF beschrieben werden wie es etwa in Southampton
> passiert.[1]
> 
>> Für die Modellierung von Verfügbarkeitsinformationen habe ich
deshalb
> 
>> die Klasse daia:Storage eingeführt (bzw. beibehalten), aber noch
> keine 
>> direkte Relation zwischen foaf/org:Organisation und daia:Storage. 
>> Möglicherweise passt besser org:Site oder gr:Location, was ist der 
>> Unterschied zwischen den beiden Klassen?
> 
> org:Site ist aauf jeden Fall flexibler, weil man es eben nicht nur
mit
> Items verknüpfen kann, sondern auch mit Services, dem Sitz von
> Abteilungen, Personen etc.
> 
>> Und wie lässt sich ausdrücken, dass einige Bücher der 
>> Hochschulbibliothek_U im Hochschulinstitut Z aufbewahrt werden,
> welches 
>> jedoch organisatorisch nicht der Bibliothek untergeordnet ist,
> sondern 
>> eine eigene Einrichtung ist?:
> 
> _:Hochschulbibliothek_U marcrel:owns _:CollectionA
> 
> _:Collection A org:Site _:SiteA
> 
> Hochschulinstitut_Z org:hasSite _:SiteA
> 
> Soviel in aller Kürze.
> 
> Ciao
> Adrian
> 
> [1] http://data.southampton.ac.uk/
> 
>> 
>> <Hochschulbibliothek_U> a foaf:Organization .
>> <Hochschulinstitut Z> a foaf:Organization .
>> 
>> <Hochschulbibliothek_U> gr:hasPOS <Hochschulinstitut Z> ?
>> 
>> <Hochschulbibliothek_U> _:holdsItemsStoredAt <Hochschulinstitut Z>
?
>> 
>> 
>> Schöne Grüße
>> Jakob
> 
> 
> 
> 
> 
> _______________________________________________
> dini-ag-kim-lld mailing list
> dini-ag-kim-lld at lists.d-nb.de
> http://lists.d-nb.de/mailman/listinfo/dini-ag-kim-lld



More information about the dini-ag-kim-lld mailing list