Antw: [dini-ag-kim-lld] Europeana Data Model und ORE
Adrian Pohl
pohl at hbz-nrw.de
Mon May 16 09:45:02 CEST 2011
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
More information about the dini-ag-kim-lld
mailing list