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

Stefan Gradmann stefan.gradmann at ibi.hu-berlin.de
Tue Jul 5 12:28:34 CEST 2011 

Hallo miteinander: ich danke Kai Eckert für die gute Zusammenfassung 
unseres Gesprächs, die eigentlich von mir hätte kommen sollen :) Wir 
setzen also in der Tat auf eine relativ kurzfristige Erweiterung des 
RDF-Standards im Sinne von Named Graphs und werden dann das jetzige, 
nicht ganz glückliche Konstrukt ersetzen. Named Graphs waren übrigens 
auch schon Bestandteil der Alpha-Version von OAI ORE und sind dann 
ebenfalls aufgrund der nicht gegebenen Standardisierung wieder daraus 
getilgt worden.
Herzliche Grüße -- Stefan Gradmann

Am 05.07.11 09:35, schrieb 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
>>
>

-- 
_____________________________________________________________
Prof. Dr. Stefan Gradmann
Humboldt-Universität zu Berlin
Berlin School of Library and Information Science
Sitz: Dorothenstrasse 26
Post: Unter den Linden 6, 10099 Berlin
Tel.: +49 30 2093-4481
Fax : +49 30 2093-4335
GSM : +49 170 8352623
e-mail: stefan.gradmann at ibi.hu-berlin.de
Public Calendar View: https://www.google.com/calendar/embed?src=stefan.gradmann%40gmail.com&ctz=Europe/Berlin
_____________________________________________________________
  Je est un autre.
(Arthur Rimbaud, Lettres du Voyant)
_____________________________________________________________

More information about the dini-ag-kim-lld mailing list