[dini-ag-kim-lld] Re: Europeana Data Model und ORE
Stefan Gradmann
stefan.gradmann at ibi.hu-berlin.de
Sat May 14 14:02:15 CEST 2011
Liebe Mitlesende und -schreibende,
nun will ich mich doch auch wenigstens kurz zu Wort melden: ich will
mich vor dieser Diskussion keinesfalls drücken (wann haben wir denn
schon mal so engagierte Fachdiskussionen? :)) - aber meine Zeit ist
leider sehr begrenzt, und ich kann mich jetzt nicht in langen
Diskussionsthreads engagieren. Ich bin aber Übermorgen (=Montag) ohnehin
mit Antoine zusammen und will versuchen, die Frage mit ihm zu
besprechen, und melde mich dann wieder zurück mit einer Antwort in der
Sache.
Mit den besten Grüßen -- Stefan Gradmann
Am 13.05.11 12:11, schrieb Kai Eckert:
> Hallo zusammen,
>
> im folgenden eine Zusammenfassung der Diskussion um das Europeana Data
> Model (EDM), die auf dem Kickoff-Workshop begonnen hat und die wir gerne
> auf der Mailingliste weiterführen würden.
>
> Links zu EDM und eine kurze Beschreibung von Europeana finden sich hier:
> https://wiki.d-nb.de/display/DINIAGKIM/Europeana
>
> Über eine Berichtigung/Ergänzung der Beschreibung durch jemanden, der
> mit Europeana besser vertraut ist, würde ich mich freuen.
>
> Im Prinzip geht es um die Verwendung von ORE in EDM und die Frage, ob es
> geeignet ist, den angestrebten Zweck zu erfüllen, unterschiedliche
> Beschreibungen identischer Resourcen, wie sie in Europeana zwangsläufig
> anfallen, zu unterscheiden.
>
> EDM nutzt dazu das Konzept der Proxies aus ORM, so dass die Aussagen zu
> den Ressourcen nicht direkt auf die Ressource bezogen werden, sondern
> auf einen Platzhalter der Ressource im Kontext einer konkreten
> Beschreibung durch einen Datenlieferanten an Europeana. Im Workshop ging
> es darum, ob das semantisch korrekt ist, wobei aber auch keine Einigkeit
> herrschte, was genau denn so ein Proxy eigentlich ist.
>
> Dazu schrieb Mirjam Kessler:
>
>> ich glaub, ich hab jetzt eine Lösung des
>> ORE-Proxy-DC:Creator-Problems. Die Lösung liegt bei der Definition
>> von Proxies in ORE und man muss genau schauen, wo die ore:proxyIn
>> und ore:proxyFor hinführen.
>>
>> OAI-ORE definiert die Verwendung von Proxies folgendermaßen:
>>
>> Ein Proxy steht für eine Aggregated ressource in einem bestimmten
>> Verwendungskontext oder einer bestimmten Aggregation
>> (repräsentiert die Aggregated Ressource also nicht global): “The
>> URI of a Proxy, indicated by URI-P throughout this specification,
>> then can be used in assertions specific to the Aggregated Resource
>> in the context of that aggregation. This contrasts with the URI-AR
>> of the Aggregated Resource, which has no special meaning relative
>> to the Aggregation. […] The URI-P of this Proxy is then available
>> for use in triples where the intended semantics is a relationship
>> specific to the Aggregated Resource in the context of the
>> respective Aggregation. Note that the assertion of Proxies is
>> OPTIONAL and unnecessary if context-specific assertions are not
>> needed.”
>>
>> Der Metadatensatz, der bei Europeana durch den Proxy repräsentiert
>> wird, ist eine spezifische Beschreibungsweise eines Providers der
>> Aggregated Ressource;
>>
>> Es ist die///context specific assertion/zu einem real world
>> object/ non-information ressource (da ore:proxyIn sich auf
>> ore:Aggregation bezieht und ore:proxyFor auf die
>> ens:aggregatedCHO) und nicht etwa einer View des Objekts
>> (ens:hasView). Somit ist es konsequent, dem Proxy den Creator des
>> real world Objekts zuzuweisen.__
>>
>> Nehmen wir das Bilder der Mona Lisa, das im Louvre hängt. Der
>> Metadatensatz im Proxy ist dann eine kontextspezifische
>> Annahme/Aussage zu diesem Bild und der Proxy selbst bzw die URI-P
>> hat die Funktion, das Bild in diesem Anwendungskontext zu
>> repräsentieren. Somit muss URI-P den Creator des Bildes haben, da
>> er für dieses steht.
>>
>> Im Prinzip hat der Proxy bei Europeana sowas wie eine
>> Doppelfunktion. Schau Dir mal das Beispiel
>> hier:_http://www.openarchives.org/ore/1.0/datamodel#InterAggr_zum
>> Thema Lineage von Proxies an. Da haben die Proxies nur eine
>> Funktion, sie repräsentieren die Aggregated Ressource in dem
>> Lineage Kontext (und hätten in dieser Funktion auch den gleichen
>> Creator wie die Aggregated Ressource). Bei Europeana kommt der
>> komische Umstand hinzu, dass die Metadaten „im“ Proxy stehen und
>> sich die kontextspezifische Funktion des Proxies über den Inhalt
>> des Beschreibungssatzes ergibt.
>>
>> Ich find‘s jetzt irgendwie plausibel, wenn auch kompliziert…
>
> Dazu meine Antwort:
>
>> irgendwie plausibel ist es schon. Das Problem ist einfach, dass ORE hier
>> sehr weitreichende Definitionen beinhaltet, über deren Gültigkeit, bzw.
>> Allgemeinverständlichkeit (im Sinne von "interoperabel im Semantic Web")
>> ich mir zumindest nicht sicher bin (vorsichtig ausgedrückt).
>>
>> Das Semantic Web, sprich RDF, sieht es derzeit einfach nicht vor,
>> Aussagen aus verschiedenen Quellen sauber zu trennen und deswegen ist
>> jeder Versuch, es über ein Modell wie ORE doch zu ermöglichen,
>> bestenfalls unsauber, schlimmstenfalls falsch.
>>
>> Aber von diesen grundlegenden Überlegungen (bei denen ich mir durchaus
>> auch nicht 100% sicher bin) abgesehen: Lass uns doch einfach mal ein
>> bisschen Logelei spielen (am bekannten Mona Lisa Beispiel).
>>
>> Der Proxy wird durch Dublin Core beschrieben, der Creator hat folgende
>> Definition: An entity primarily responsible for making the resource.
>>
>> Daraus leite ich ab, dass das, was da als Text steht, eine Entität
>> identifiziert. Das kann dann wohl nur, da sind wir uns wohl einig, "Da
>> Vinci" sein. Eine Interpretation als String, der auf einer Karteikarte
>> steht, gibt die Dublin Core Definition nicht her.
>>
>> Weiterhin muss dann das, auf was sich die Aussage bezieht, die Resource
>> sein, die Da Vinci erstellt hat. Das ist wohl ebenfalls weitgehend
>> unstreitig die "Mona Lisa". Also ist unser Proxy die Mona Lisa. Der
>> andere Proxy ist nach der Argumentation ebenfalls die Mona Lisa, woraus
>> sich ableiten lässt, dass proxy1 owl:sameAs proxy2.
>>
>> Das ist glaube ich nicht ganz kompatibel zur Idee des Proxies, denn die
>> gleichsetzung aller Proxies ist für ORE recht fatal...
>>
>> Ich habe aber sowieso das Gefühl, dass ORE hier ein bisschen arg gedehnt
>> wird. Die Idee des Proxies ist es ja gerade, dass es eine aggregierte
>> Resource im Kontext der Aggregation repräsentiert und ausschließlich
>> Informationen damit assoziiert werden, die die Rolle der AR innerhalb
>> der Aggregation betrifft. Also eben zum Beispiel die Position der AR in
>> einer geordneten Liste. Das ist dann aber eben eine Eigenschaft, die
>> tatsächlich nicht die AR betrifft, sondern nur die Aggregation. Der
>> Titel und Ersteller einer Resource ist aber eben gerade eine
>> Information, die sich auf die AR bezieht und nicht auf die Aggregation.
>> Der einzige Ausweg wäre da (wie im Workshop gesagt), dass man ein neues
>> Vokabular nutzt, dass eine zu ORE kompatible Definition hat und zum
>> Beispiel festhält, dass eine AR innerhalb einer Aggregation (und nur da)
>> den folgenden Titel erhält. Das scheint mir auch gewollt, ist aber
>>
>> a) eben nicht mit Dublin Core machbar, ohne die oben gezeigten Konflikte
>> zu erzeugen und
>>
>> b) für die Nachnutzung der Daten wenig hilfreich, da gerade die
>> interessanten Informationen (was gibt es an Resourcen und dazugehörigen
>> Informationen) nicht direkt verfügbar sind.
>>
>> Langer Text, ich hoffe, das macht Sinn. :-)
>
> Zuletzt die Antwort von Stefanie Rühle:
>
>> Kai schreibt, dass ORE seines Erachtens hier "arg gedehnt" wird. Und ich
>> denke, damit hat er Recht.
>>
>> Mirjam schreibt:
>>> Der Metadatensatz, der bei Europeana durch
>>> den Proxy repräsentiert wird, ist eine spezifische
>>> Beschreibungsweise eines Providers der Aggregated Ressource; …
>>
>> Ich kann der Definition von Proxy in OAI-ORE nirgends entnehmen, dass
>> der
>> Proxy dazu gedacht ist, den Metadatensatz zu repräsentieren. Er ist doch
>> eigentlich nur da, um die Beziehung zwischen den Aggregierten
>> Resourcen näher
>> zu beschreiben, nicht die Ressourcen selbst. Oder? Zudem wird auch in
>> den
>> Folien von Steffen Hennicke der Proxy nicht dazu verwendet, den
>> Metadatensatz
>> zu repräsentieren, denn der wäre doch eine information resource (es
>> sei denn,
>> wir reden tatsächlich über Katalogkarten;-) In den Folien
>> repräsentiert der
>> Proxy das ens:PhysicalThing. Und ens:PhysicalThing wird in EDM
>> folgendermaßen
>> definiert:
>>
>> "A persistent physical item such as a painting, a buildung, a book or a
>> stone."
>>
>> Außerdem wird es als subclass von ens:NonInformationResource
>> deklariert. Ein
>> Metadatensatz wäre - wie schon gesagt - eine information resource.
>> Also ist
>> hier von Metadaten offensichtlich gar nicht die Rede;-) Hier geht es
>> doch
>> vielmehr darum, dass der Proxy ein Platzhalter für das Real Physical
>> Object
>> ist. So ist es ja auch in ORE gedacht (das der Proxy ein Platzhalter
>> ist,
>> egal für welche Art von Ressource). Aber ist das wirklich in der Form
>> gemeint, in der Europeana es verwendet? In der OAI-ORE-Spezifikation
>> steht
>> doch:
>>
>> „The URI-P of this Proxy is then available for use in triples where the
>> intended semantics is a relationship specific to the Aggregated
>> Resource in
>> the context of the respective Aggregation.“
>>
>> Der Proxy wird also verwendet, um die Beziehung zwischen Objekten
>> innerhalb
>> einer bestimmten Aggregation näher zu bestimmen
>> „a Proxy, which is a Resource that "stands for" an Aggregated
>> Resource in a
>> manner that is specific to one Aggregation„
>>
>> Properties wie Verfasser, Titel, Erscheinungsdatum usw. in der Form,
>> wie sie
>> in Folie 22 verwendet werden, sind keine properties, die die Beziehungen
>> zwischen den Ressourcen innerhalb der Aggregation näher bestimmen und
>> aus
>> diesem Grund gehören sie m. E. auch nicht zur Beschreibung des proxy,
>> sondern
>> zu der Beschreibung des physicalThing. In RDF könnte man das m. E. dann
>> folgendermaßen darstellen:
>>
>> Beschreibung der Aggregation:
>> --------------------------------------
>>
>> ex:myDissertationumAggregation rdf:type ore:aggregation ;
>> ore:aggregates sbb:physical-613226798-LOG_0000 ,
>> gbv:physical-535703414 .
>>
>> Der Proxy der einen aggregierten Ressource:
>> -----------------------------------------------------
>>
>> sbb:proxy-613226798-LOG_0000 rdf:type ore:proxy ;
>> ore:proxyFor sbb:physical-613226798-LOG_0000 ;
>> ore:proxyIn ex:myDissertationumAggregation ;
>> skos:exactMatch gbv:proxy-535703414.
>>
>> Der Proxy der anderen aggregierten Ressource:
>> ---------------------------------------------------------
>>
>> gbv:proxy-535703414 rdf:type ore:proxy ;
>> ore:proxyFor gbv:physical-535703414 ;
>> ore:proxyIn ex:myDissertationumAggregation ;
>> skos:exactMatch sbb:proxy-613226798-LOG_0000
>>
>> Beschreibung der einen non-information resource
>> ------------------------------------------------------------
>>
>> sbb:physical-613226798-LOG_0000 rdf:type ens:physicalThing ;
>> dct:title "Dissertationum Exegeticarum De Melchisedeco" .
>>
>> Beschreibung der anderen non-information resource.
>> ----------------------------------------------------------------
>>
>> gbv:physical-535703414 rdf:type ens:physicalThing ;
>> dct:title "Dissertationum Exegeticarum De Melchisedeco Ad Gen. XIV.
>> 18. seqq.
>> & Ebr. VII. 1. sqq. Secunda; (Antehac A. 1681 Gryphiswaldiae data
>> occasione
>> proposita, iam vero ... revisa& recusa) Exponens Originem Viri ac
>> Stirpern"
>> .
>>
>>
>> Ich bin jetzt davon ausgegangen, dass die URIs, die in der Folie in dem
>> physicalThing stehen, tatsächlich auch das physical thing
>> identifizieren.
>> Aber ich befürchte, dem ist gar nicht so. Schaut man sich die URIs
>> an, stellt
>> man fest, dass hier wohl die ID des Metadatensatzes verwendet wurde,
>> um eine
>> URI zu generiern. Aber was identifiziert diese URI? Das Real Physical
>> Object
>> (so sieht es jedenfalls in Folie 22 aus) oder das Digital Representation
>> Object (dann wäre PhysicalThing m. E. allerdings nicht die richtige
>> Klasse,
>> anstelle dessen müsste WebResource verwendet werden, oder)? Oder geht es
>> vielleicht doch um den Metadatensatz, wie Mirjam angenommen hat?
>>
>> Hier wird schon mal deutlich, was für Probleme es mit sich bringt,
>> wenn nicht
>> eindeutig ist, was eigentlich beschrieben wird – eine Diskussion, die
>> wir ja
>> schon in der Session hatten. Also was identifiziert die URI
>> sbb:physical-613226798-LOG_000 eigentlich? Und davon ausgehend: wofür
>> steht
>> der Proxy tatsächlich. Und wenn er für das Real Physical Object
>> steht, warum
>> werden dann die Properties, die zum Real Physical Object gehören,
>> nicht auch
>> zur Beschreibung desselben verwendet? Weil das Real Physical Object
>> keine
>> wirkliche internetfähige URI hat? Warum wird dann anstelle des Physical
>> Object nicht das Digital Representation Object beschrieben? Dort
>> ließe sich
>> das URI Problem doch lösen, oder? Die „digital representaion“ wird
>> aber in
>> den Folien von Herrn Hennicke irgendwie gar nicht berücksichtigt. Es sei
>> denn, die oben genannten URIs stehen doch für die digitale Version.
>> Fragen
>> über Fragen und bisher keine Antwort. Ich werde mir zumindest das
>> METS/MODS
>> Mapping jetzt noch mal genauer anschauen. Vielleicht wird es mir dann
>> klarer.
>>
>> Die Folien von Herrn Hennicke sind hier:
>>
>> https://wiki.d-nb.de/download/attachments/44107131/20110427_KIM_EDM.ppt?versi
>>
>> on=1&modificationDate=1304955506000
>>
>> Die OAI-ORE Spezifikation hier:
>> http://www.openarchives.org/ore/1.0/datamodel#RDF_Graph_Advanced
>>
>> Also: Fortsetzung folgt!
>>
>> Viele Grüße aus Nürnberg
>>
>> Stefanie
>
> So, jetzt ist die Mail richtig schön lang und die Diskussion eröffnet :-)
>
> Schönes Wochenende und viele Grüße,
>
> Kai
--
_____________________________________________________________
Prof. Dr. Stefan Gradmann
Humboldt-Universität zu Berlin
Berlin School of Library and Information Science
Sitz: Dorothenstrasse 26
Post: Unter den Linden 6, 10099 Berlin
Tel.: +49 30 2093-4481
Fax : +49 30 2093-4335
GSM : +49 170 8352623
e-mail: stefan.gradmann at ibi.hu-berlin.de
_____________________________________________________________
Je est un autre.
(Arthur Rimbaud, Lettres du Voyant)
_____________________________________________________________
More information about the dini-ag-kim-lld
mailing list