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

[Kai Eckert]

Hallo zusammen,

ich möchte noch mal eine Rückmeldung zu dieser Diskussion geben, die ja 
im Prinzip noch zwei offene Fragen hat, die mich auch nach den Mails 
noch weiter beschäftigt haben.

Zum Einwand von Adrian: Schaut man in die technische Spezifikation, 
sprich, die RDFS-Beschreibung, so findet sich keine Einschränkung für 
AggregatedResource [1]. Insofern spricht aus meiner Sicht schon mal 
nichts dagegen, da für mich diese Definitionen und Einschränkungen im 
Zweifelsfall den Ausschlag geben. Im Primer ist stets von Web Ressourcen 
die Rede, speziell von Ressourcen wie Text, Bilder, Audio, ... Nach 
meiner Einschätzung hatte man beim Schreiben dieser Texte wohl eher 
klassische Webressourcen (also information resources) im Sinn, aber da 
in der Spezifikation dazu keine Einschränkung gemacht wird, sehe ich 
kein Problem.

Zur Nutzung von Dublin Core: Ich habe in der Zwischenzeit persönlich mit 
Stefan Gradmann gesprochen. Er sieht das Problem mit der Nutzung von 
Dublin Core genau so, da hat sich also relativ unstreitig eine 
Inkonsistenz in das Datenmodell eingeschlichen. Beheben lässt sich das 
jetzt nicht ohne größeren Aufwand, da das Modell ja schon ausgiebig 
vorgestellt wurde und wird.

Es ist auch nicht sinnvoll, da jetzt noch nachzuarbeiten: Es wird gerade 
an einer neuen RDF-Version gearbeitet, die voraussichtlich Mitte 2012 
fertig ist und die endlich eine Möglichkeit beinhalten soll, 
Metainformationen im Stil von Named Graphs zu repräsentieren. Antoine 
Isaac hatte mir schon letztes Jahr gesagt, dass er eine derartige 
Repräsentation für das EDM vorziehen würde, mangels eines Standards 
schied das aber noch aus. Mit der neuen RDF-Version wird also auch das 
EDM überarbeitet werden, um von den neuen Möglichkeiten zu profitieren, 
dabei kann dann die Inkonsistenz mit Dublin Core beseitigt werden, bzw. 
vermutlich tritt sie dann nicht mehr auf, da nicht mehr mit Proxies 
gearbeitet werden muss.

Das ganze ist ein schönes Beispiel, welche Fallstricke lauern, wenn 
Daten plötzlich eine feste Semantik mitbringen; ob und wie 
Unsauberkeiten beim Umgang damit zum Problem werden und wie Semantic Web 
Anwendungen damit umgehen (können), wird sich wohl erst noch zeigen.

[1] http://www.openarchives.org/ore/terms/

Viele Grüße,

Kai

Am 16.05.2011 09:45, 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
>

-- 
Kai Eckert
Universitätsbibliothek Mannheim
Fachreferat Mathematik, Informatik, Wirtschaftsinformatik
Schloss Ostfluegel
68131 Mannheim
Tel. 0621/181-2946  Fax 0621/181-2918