Angabe der Affiliation bei Urheber*innen

acka47 commented 4 years ago

Momentan gibt es gemäß dem Schema keine Option, bei Urheber*innen eine affiliierte Organisation mitzugeben. Ein bedarf dazu hat sich im OERSI-Kontext ergeben. Es gibt in schema.org zwei Optionen dies zu ergänzen.

1. `sourceOrganization`

{
   "@context":"http://schema.org",
   "id":"https://www.oerbw.de/edu-sharing/components/render/aa665d6d-b911-4eec-a2aa-7d593721b838",
   "creator":[
      {
         "type":"Person",
         "name":"Michael Menzel"
      }
   ],
   "sourceOrganization":{
      "id":"http://www.wikidata.org/entity/Q153978",
      "name":"Universität Tübingen"
   }
}

2. `affiliation`

{
   "@context": "http://schema.org",
   "id":"https://www.oerbw.de/edu-sharing/components/render/aa665d6d-b911-4eec-a2aa-7d593721b838",
   "creator":[
      {
         "type":"Person",
         "name":"Michael Menzel",
         "affiliation":{
            "id":"http://www.wikidata.org/entity/Q153978",
            "name":"Universität Tübingen"
         }
      }
   ]
}

Beide Optionen haben Vor- und Nachteile.

acka47 commented 4 years ago

Ich persönlich präferiere 2.), weil es die affiliierte Organisation an der richtigen Stelle angibt, indem die Information klar an die Person koppelt und nicht an das Material.

Unter bestimmten Bedingungen könnten dadurch aber ein Problem entstehen. Angenommen die Person ist durch eine URI identifiziert (von ORCID, Wikidata, OER World Map o.ä.) und das System aktualisiert Personendaten in Ressourcenbeschreibugnen regelmäßig automatisch durch Abfrage der strukturierten Daten hinter der Personen-URI. Nach einem Wechsel der Organisation würde dann bei der Person nach einem Wechsel die aktuelle Affiliierung angezeigt werden und nicht jene, die sie bei Erstellung des Materials hatte. Für diesen Fall könnte eine separate Erfassung der sourceOrganisation praktisch sein. Dieser Einwand spräche evtl. sogar dafür, nicht nur sourceOrganization zu benutzen, sondern sogar beide Optionen zu unterstützen...

mirjan-hoffmann commented 4 years ago

Ich bin für Möglichkeit 1.). Damit können wir auch Fälle abdecken, in denen kein Autor, aber eine Institution angegeben ist (was vorkommen kann). In unseren konkreten Fällen im oersi (oernds.de und zoerr) haben wir derzeit gar keine explizite Zuordnung von Autor zu Institution - hier wäre es also sowieso schwierig 2.) zu setzen, man hätte nur die Möglichkeit zu sagen "jeder Autor gehört automatisch zur gesetzten Institution". Zudem das oben geschilderte Problem. Daher wäre ich dafür mit der Umsetzung von 1.) zu beginnen und 2.) zusätzlich einzubauen, sobald der Bedarf dafür gegeben ist.

Allgemein frage ich mich noch, ob es Sinn macht hier über ein Array nachzudenken. In oernds und zoerr werden derzeit nur Einzelwerte unterstützt. Ich bin aber nicht sicher wie die Praxisfälle aussehen können. Gibt es OER, die von verschiedenen Autoren an unterschiedlichen Hochschulen erstellt werden? Gibt es Autoren, die gleichzeitig für verschiedene Institutionen arbeiten? Da ich kein solches Praxisbeispiel kenne, ist es vielleicht einfacher zuerst mit Einzelwerten anzufangen?!

axel-klinger commented 4 years ago

Das Beispiel mit dem Wechsel der Organisation spricht aus meiner Sicht dafür, nur die sourceOrganisation zu verwenden, und nicht die affiliation. Wer die neue Organisation des Autors ist, interessiert ja an dieser Stelle nicht. Der Fokus liegt auf dem Material, und das wurde für die sourceOrganisation bereitgestellt.

Wenn wir dann aber weiterdenken und mehrere Organisationen zulassen wollen, dann wäre vielleicht doch die direkte Zuordnung aus 2) interessant. Beispiel hierfür könnten unsere Lehrtandems sein, bei denen Material von Prof A aus Orga X und Prof B aus Orga X bereitgestellt werden. Ich hätte aber auch aus o.g. Gründen kein Problem damit, wenn es hier keine direkte Zuordnung gäbe, und wir einfach zwei Personen und zwei Organisationen angeben würden. Wie gesagt, sollte der Fokus auf dem Material liegen.

acka47 commented 4 years ago

Prinzipiell fände ich es schade, wenn wir die Möglichkeit aufgeben würden, Personen mit Organisationen zu assoziieren und gehe davon aus, dass zukünftig entsprechende Anforderungen zur Anzeige von OER-Beschreibungen auftauchen werden. D.h. ich neige immer noch zur Nutzung von affiliation.

Meinem eigenen Einwand mit dem Wechsel der Affiliation (oder des Namens) könne mensch ja begegnen, indem die Personendaten eben nicht automatisiert aus einem verlinkten Personenprofil aktualisiert werden. Dann hätten wir am Material immer Personennamen und Affiliierung zum Zeitpunkt der Publikation des Materials und könnten den aktuellen Namen und die aktuelle Affiliierung im verlinkten Profil anschauen.

Für die Entscheidungsfindung, betrachte ich den von @axel-klinger genannten Fall mit mehreren Creators hier einmal näher anhand eines Beispiels. Sollten wir uns auf sourceOrganization einigen, bedeutet das auf jeden Fall schon einmal, bei diesem Feld im Schema einen Array zu erwarten.

Angenommen folgendes Beispiel: Ali A. (TH Köln), Bea B. (HS Bochum) und Cora C. (FH Bielefeld) erstellen in einem Projekt "Einführung in die Betriebswirtschaftslehre" gemeinsam Materialien. Mit sourceOrganization würden die Metadaten etwa so aussehen:

{
    "@context": "http://schema.org",
    "id": "https://example.org/bwl-oer",
    "creator": [
        {
            "type": "Person",
            "name": "Ali A"
        },
        {
            "type": "Person",
            "name": "Bea B"
        },
        {
            "type": "Person",
            "name": "Cora C"
        }
    ],
    "sourceOrganization": [
        {
            "id": "http://www.wikidata.org/entity/Q54166",
            "type": "Organization",
            "name": "Technische Hochschule Köln"
        },
        {
            "id": "http://www.wikidata.org/entity/Q1622078",
            "type": "Organization",
            "name": "Hochschule Bochum"
        },
        {
            "id": "http://www.wikidata.org/entity/Q1391181",
            "type": "Organization",
            "name": "Fachhochschule Bielefeld"
        }
    ]
}

Hier lassen sich wie gesagt die Organisationen nicht der Person zuordnen. Das wäre für Axel hinnehmbar, ich würde diese Möglichkeit wie gesagt ungern aufgeben und sehe auch keinen überzeugenden Grund dafür, warum wir dies tun sollten.

Mit affiliation sähe es so aus:

{
    "@context": "http://schema.org",
    "id": "https://example.org/bwl-oer",
    "creator": [
        {
            "type": "Person",
            "name": "Ali A",
            "affiliation": {
                "id": "http://www.wikidata.org/entity/Q54166",
                "type": "Organization",
                "name": "Technische Hochschule Köln"
            }
        },
        {
            "type": "Person",
            "name": "Bea B",
            "affiliation": {
                "id": "http://www.wikidata.org/entity/Q1622078",
                "type": "Organization",
                "name": "Hochschule Bochum"
            }
        },
        {
            "type": "Person",
            "name": "Cora C",
            "affiliation": {
                "id": "http://www.wikidata.org/entity/Q1391181",
                "type": "Organization",
                "name": "Fachhochschule Bielefeld"
            }
        }
    ]
}

Die Anforderung in diesem Ticket ist verwandt mit der Anforderung, ein Projekt zu erfassen, in dessen Rahmen eine OER erstellt wurde (#17). (Auch für diesen Fall könnte sourceOrganization verwendet werden, was aber verhindert werden sollte, damit das Feld nicht uneinheitlich genutzt wird.)

acka47 commented 4 years ago

@mirjan-hoffmann schrieb:

In unseren konkreten Fällen im oersi (oernds.de und zoerr) haben wir derzeit gar keine explizite Zuordnung von Autor zu Institution - hier wäre es also sowieso schwierig 2.) zu setzen, man hätte nur die Möglichkeit zu sagen "jeder Autor gehört automatisch zur gesetzten Institution".

und

In oernds und zoerr werden derzeit nur Einzelwerte unterstützt.

Das heißt, es gibt derzeit Fälle mit mehreren Autor*innen und einer Organisation aber nicht mit mehreren Organisationen in eduSharing, oder? Wie auch schon in #8 besprochen sollten wir prinzipiell nicht problematische Daten aus EduSharing zum Anlass nehmen, das Schema zu verwässern.

Gibt es OER, die von verschiedenen Autoren an unterschiedlichen Hochschulen erstellt werden?

Wie in #17 geschrieben, wird dieser Fall in der OER-Content.NRW-Förderlinie häufig vorkommen.

acka47 commented 4 years ago

Eine Sache fiel mir gerade noch ein: Ein Ziel des LRMI-Profils sollte sein, nach Möglichkeit auf dem HS-OER-LOM-Profil basierende Beschreibungen ohne Verlust in das LRMI-Profil transformieren zu können und andersherum.

In Bezug auf dieses Ticket bedeutet das: Im HS-OER-LOM-Profil würde die Affiliierung sinnvollerweise innerhalb der vCard einer Person mit ORG angegeben werden (in den Beispielen findet sich so etwas allerdings nicht). Der dazu äquivalente Ansatz im JSON-Schema wäre die Nutzung von affiliation.

Leider befürchte ich, dass es so einfach nicht ist. Ich habe die dunkle Ahnung, dass HS-OER-LOM in dieser Hinsicht auch mit Blick auf EduSharing entwickelt wurde und dass – zumindest im XML, das über die OAI-PMH-Schnittstelle einer EduSharing-Instanz kommt – derzeit die Organisation nie in der vCard auftauchen wird, sondern in einem anderen Feld (meine Vermutung wäre anhand der Beispiele in HS-OER-LOM metametadata.contribute). Da müsste ich mir mal eine entsprechende Schnittstelle genauer anschauen. Aber auch in diesem Fall gilt, dass die Datenmodellierung in EduSharing nicht als Richtschnur für unser Schema gelten sollte

mirjan-hoffmann commented 4 years ago

Ich stimme Dir zu, dass wir keine schlechte API definieren sollten, nur weil ein anderes System die Daten so anbietet. Ich würde es aber durchaus als legitim ansehen, dass man eine Institution zu einer OER angibt, aber keinen Autor - zB wenn der Autor nicht genannt werden möchte. Dies wäre mit der affiliation Lösung ja gar nicht darstellbar. Wenn wir uns darüber im Klaren sind und diese Fälle bewusst ausschließen wollen, dann bin ich auch mit Ansatz 2. einverstanden.

Solange nur davon ausgegangen wird, dass ein Anforderung kommt, aber noch kein konkreter Bedarf da ist, würde ich auch sagen, dass dies zwar unsere Entscheidungen lenken kann, aber nicht bestimmen sollte.

acka47 commented 4 years ago

Ich würde es aber durchaus als legitim ansehen, dass man eine Institution zu einer OER angibt, aber keinen Autor - zB wenn der Autor nicht genannt werden möchte. Dies wäre mit der affiliation Lösung ja gar nicht darstellbar.

Dafür gibt es mit dem derzeitigen zwei Möglichkeiten:

direktes ergänzen der Organisation als creator
Nutzung der publisher property.

Würde eine der beiden Optionen für deinen Use Case ausreichen? Ich hätte auf jeden Fall Bedenken, eine dritte Möglichkeit zu ergänzen.

acka47 commented 4 years ago

In einem Gespräch haben wir uns auf folgende Lösung geeinigt:

Für das LRMI-Profil nutzen wir die glatte Lösung mit affiliation. (Umsetzung hat aber erstmal nicht Priorität, so dass das Ticket offenbleibt.)
In OERSI werden wir das Feld sourceOrganization ergänzen und, sobald der affiliation-Ansatz in Datenquellen genutzt wird, auch diesen unterstützen.

acka47 commented 3 years ago

Hier meine Anmerkungen zu @mirjan-hoffmann's Kommentar in https://github.com/dini-ag-kim/lrmi-profile/pull/98#pullrequestreview-740236829. Prinzipiell verstehe ich das so, dass die in https://github.com/dini-ag-kim/lrmi-profile/issues/15#issuecomment-689517903 dokumentierte Einigung hinfällig ist und wir die Diskussion wieder aufnehmen müssen. Damit alles beisammen bleibt, machen wir das am besten in diesem Ticket. @mirjan-hoffmann schreibt:

Jedenfalls zur Ergänzung von affiliation: habe dies heute morgen einmal mit Axel diskutiert. Wie ja schon im Issue https://github.com/dini-ag-kim/lrmi-profile/issues/15 besprochen, ist dieses Feld ja nicht ganz intuitiv zu verstehen und es sind mehrere mögliche Vorgehensweisen denkbar. Die Zugehörigkeit zu einer Institution kann sich ja ändern. Werden Autoren zB über eine ORCID oä geladen, dann ist die Zugehörigkeit zu einer Institution immer abhängig vom Zeitpunkt wann die Autor-Daten geladen werden. Hier müsste also definitiv klar gestellt sein, dass die Zugehörigkeit für einen festen Zeitpunkt gilt.

Ich gehe davon, dass es hier eine gängige Praxis in der Wissenschaft gibt. Angegeben wird die Affiliierung der Autor*innen zum Zeitpunkt der Erstellung/Publikation der Ressource. Ist eine ORCID-Angabe vorhanden lässt sich dort bestenfalls die Historie der Affiliierungen und damit auch die aktuelle Affiliierung abrufen.

Auch welchen Zeitpunkt. Wenn man dateCreated oder datePublished dafür wählt, dann sollte auch noch genauer definiert werden was genau diese Datumswerte ausdrücken. Ist datePublished zB das Erst-Veröffentlichungsdatum des Materials oder das Letzte?

Ich würde sagen, es handelt sich um das Datum, an dem die beschriebene Version des Materials veröffentlicht wurde. Mit dateCreated ließe sich angeben, wenn die Erstellung schon deutlich vorher stattgefunden hat, mit isBasedOn auf vorher publizierte Versionen verweisen, die ein anderes datePublished haben können.

Haben alle Nutzer/Anbieter das gleiche Verständnis der Definitionen? Evtl sollten wir diese Fragen nochmal genauer erörtern und die Dokumentation entsprechend anpassen.

+1

Da Änderungen des Feldes wahrscheinlich einen API-break zur Folge hätten, sollten wir uns bei Einführung genau klar darüber sein, dass es so passt.

Meinst du einen API-break bei OERSI? Das muss ja nicht sein, wir könnten auch einfach erstmal affiliation ergänzen und für die Filter im ETL zusätzlich sourceOrganization befüllen. Das sollten wir aber nicht hier diskutieren.

mirjan-hoffmann commented 3 years ago

Ich würde nicht sagen, dass es hinfällig ist. Es sollte nur gut dokumentiert sein, damit klar ist wie es verwendet wird (auf Grund der verschiedenen Interpretationsmöglichkeiten). Aber am Besten wird dies am Dienstag nochmal direkt mit Axel diskutiert.

Meinst du einen API-break bei OERSI? Das muss ja nicht sein, wir könnten auch einfach erstmal affiliation ergänzen und für die Filter im ETL zusätzlich sourceOrganization befüllen. Das sollten wir aber nicht hier diskutieren.

Nein, ich meinte damit, dass das Feld affiliation bei Einführung wirklich gut durchdacht sein sollte und allen klar sein sollte was es bedeutet. Stellt sich nämlich im Nachhinein heraus, dass affiliation doch nochmal anders definiert werden sollte, dann wäre dies vermutlich mit einem API-break verknüpft.

acka47 commented 3 years ago

@mirjan-hoffmann , reicht dir https://github.com/dini-ag-kim/lrmi-profile/commit/a7e3cb33f87f88ea927f55662e7c456e39f64af7 als Klarstellung zu affiliation? Ich würde ungern weiter ins Detail gehen, da wir ja hier auch sonst keine Katalogisierungsregeln machen.

mirjan-hoffmann commented 3 years ago

Ja, passt (habe auch mit @axel-klinger nochmal drüber gesprochen)

dini-ag-kim / amb