[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