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

[Kai Eckert]

Und weil es so schön ist, antworte ich mir auch gleich selbst, bzw. 
Stefanie ;-)

> 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?

So habe ich das auch verstanden. Ich denke, Mirjam meinte, dass durch 
diese Konstruktion erreicht werden soll, dass die Daten bezüglich der 
Ressource aus einer Quelle zusammengefasst werden, was letztlich dem 
entspricht, was wir als Metadatensatz bezeichnen würden.

>> 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.

Ich denke, man könnte die Daten zur schon als Properties des Proxies 
erfassen, aber eben nicht mit Dublin Core.

>> 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.

Hat zwar nichts mit EDM zu tun, aber hier machst du den gleichen Fehler: 
skos:exactMatch kannst du hier nicht verwenden, ohne dass du 
gleichzeitig die Proxies zu skos:Concepts erklärst. Jetzt sind sie also 
schon Proxies, Gemälde/Bücher und Konzepte... :-)

>> 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?

Das muss man einfach definieren. Da du Dublin Core verwendest, kann es 
sich eigentlich nur um das Physical Object handeln. Dass die URI aus der 
ID des Metadatensatzes generiert wurde, muss nichts heißen. Im Linked 
Data Service der UB Mannheim verwenden wir auch URIs, die aus der PPN 
des Titeldatensatzes generiert wurden, aber wir identifizieren damit das 
Buch, dass durch den Titeldatensatz beschrieben wurde. Natürlich kann 
das Buch auch andere URIs haben, z.B. basierend auf den IDs anderer 
Titeldatensätze.

>> 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?

+1 für eine saubere Definition aller verwendeten URIs. Dazu sollte es 
auch mal eine Best-Practice geben, wo man solche Definitionen 
hinterlegen und nachschlagen kann.

>> 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.

Ich möchte mal ein Beispiel einbringen, wie ich mir die Verwendung von 
ORE vorstellen könnte:

gbv:proxy-535703414 rdf:type ore:proxy ;
  ore:proxyFor gbv:physical-535703414 ;
  ore:proxyIn ex:myDissertationumAggregation ;
  ex:assignedTitle "Dissertationum Exegeticarum De Melchisedeco" .

Die Logik ist dann, dass hier dem Physical Object gar kein Titel 
zugewiesen ist, gemäß ORE das Physical Object aber im Kontext der 
vorliegenden Aggregation einen Titel zugewiesen bekommen hat. 
ex:assignedTitel hätte dann die Domain ore:Proxy und das ist wohl auch 
das, was man im EDM erreichen wollte.

So ist es meiner Meinung nach semantisch korrekt, allerdings für 
Nachnutzer schwer zu verstehen, weil ORE verstanden werden muss und die 
genutzten Properties keine allgemein verständlichen Properties wie 
Dublin Core sind.

Andererseits ist es auch im jetzigen Fall schwer zu verstehen und die 
Nachnutzung streng genommen gar nicht möglich, weil das Modell 
inkonsistent ist durch die Nutzung von Dublin Core.

Viele Grüße,

Kai