[dini-ag-kim-lld] Europeana Data Model und ORE
Kai Eckert
eckert at bib.uni-mannheim.de
Fri May 13 12:11:59 CEST 2011
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
More information about the dini-ag-kim-lld
mailing list