Antw: [dini-ag-kim-lld] Europeana Data Model und ORE

[Adrian Pohl]

Liebe Leute,

ich habe gestern beim LOD-LAM-Summit in San Francisco Antoine Isaac zu
diesem Thema befragt, der das EDM mitentwickelt hat. Er sagte mir, dass
Herbert Van de Sompel (einer der Entwickler von OAI-ORE) bei der
Entwicklung des EDM konsultiert wurde und keine Einwände gegen die Art
und Weise des Gebrauchs von OAI-ORE im EDM hatte.

Demnach scheint es durchaus mit der Intention von OAI-ORE
übereinzustimmen, Non-Information Resources in einer ore:Aggregation zu
aggregieren.

Viele Grüße
Adrian


Am Montag, den 16.05.2011, 09:45 +0200 schrieb Adrian Pohl:
> Hallo,
> 
> ich sehe ein grundlegendes Problem des EDM darin, dass Non-Information
> Resources Teil einer OAI-ORE-Aggregation sein können. OAI-ORE ist m.E.
> allein für die Aggregierung von Information Resources gedacht. Das sind
> Webressourcen, die über das HTTP-Protokoll abgerufen werden können. 
> Siehe [1], wo es heißt:
> 
> "Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines
> standards for the description and exchange of aggregations of Web [!]
> resources."
> 
> Ich würde sagen der im Zitat benutzte Terminus "Web Resource"
> entspricht dem, was anderswo "Information Resource" genannt wird. Oder
> irre ich mich?
> 
> Auch heißt es: "frequently a logical unit of web [1] information is
> actually an aggregation of Resources" und es folgen Beispiele, die
> sämtlich auf Aggregationen von Web-Resourcen (im Sinne von
> Non-Information Resources) bezugnehmen.
> 
> Stefanie Rühle hatte geschrieben:
> 
> >> 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."
> 
> Genau das scheint mir eben ein Problem zu sein.
> 
> >> 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).
> 
> Dem "egal für welche Art von Ressource" würde ich nicht zustimmen. Wenn
> in einer ore:Aggregation nur Information Resources aggregiert werden,
> können ore:Proxys auch nur Information Resources im Kontext der
> Aggregation repräsentieren.
> 
> Viele Grüße
> Adrian
> 
> [1] http://www.openarchives.org/ore/1.0/datamodel 
> 
> 
>  >>>Kai Eckert <eckert at bib.uni-mannheim.de> schrieb am Freitag, 13. Mai
> 2011 um
> 12:11:
> > 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:
> 
> 
> 
> ---------
> Besuchen Sie das hbz auf dem 100. Deutschen Bibliothekartag in Berlin
> an Stand A 18!
> 
> 
>   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
> > _______________________________________________
> > 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
> _______________________________________________
> 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


---------
Besuchen Sie das hbz auf dem 100. Deutschen Bibliothekartag in Berlin an Stand A 18!