Angabe eines Projekts als Entstehungszusammenhang einer Ressource

[acka47]

OER entstehen häufig im Rahmen von Projekten, an denen mehrere Institutionen beteiligt sein können. In NRW – und soweit ich weiß auch in Niedersachsen – wurde angedacht, diese Projekte zu erfassen, ihnen also eigene Identifier und strukturierte Beschreibungen zu geben. Eine Anforderung wäre dann, in einem Projekt entstandene OER mit dem Projekt zu verlinken, um schließlich Materialien – etwa in OERSI – nach Projekt filtern zu können.

Nehmen wir als Beispiel OER-Content.NRW, wo Materialien durch Konsortien aus mindestens drei Organisationen erstellt werden. Das Projekt "Einführung in die Betriebswirtschaftslehre" (mit der beispielhaften URI https://example.org/bwl-oer) wird etwa von einem Konsortium aus sieben Organisationen durchgeführt.

Materialien sollen nach Herkunftsprojekt gefiltert werden, d.h. ich muss das Material in den Metadaten irgendwo einem Projekt zuordnen. Dafür würde sich etwa sdo:producer anbieten (sdo:Project ist derzeit als ein Untertyp von Organization in pending eingetragen, so dass es hier auch mit dem für producer erwarteten Typ Organization passen würde):

{
    "@context": "http://schema.org",
    "id": "https://example.org/bwl-oer",
    "producer": [
        {
            "id": "http://example.org/bwl-projekt",
            "type": "Project",
            "name": "Einführung in die Betriebswirtschaftslehre"
        }
    ]
}

[oellers]

Ein weiterer Zusammenhang, der eine Angabe des Projektes aus Nutzersicht relevant werden lässt, besteht in projektspezifischen (Qualitäts-)Standards, die ggf. anderweitig nicht als Informationen in Metadaten vorliegend sind.

[acka47]

Im heutigen Treffen haben wir besprochen, dass wir mal schauen sollten, ob die Ergänzung wirklich nötig ist. Wir haben ja bereits publisher und affiliation, um Organisationen und/oder Projekte zu verlinken. Außerdem gibt es #102, das verwandt ist.

[acka47]

To Do (laut Treffen vom 2023-03-14): Dokumentation (in einem How To oder FAQ), wie auf Basis der bestehenden Spec am besten Projektinformationen ergänzt werden.

[oellers]

To Do (laut Treffen vom 2023-03-14): Dokumentation (in einem How To oder FAQ), wie auf Basis der bestehenden Spec am besten Projektinformationen ergänzt werden.

Wurde in der Aufgabe im Kanban integriert

[oellers]

@acka47 schema.org Sub-Types werden bei der Schema-Validierung im AMB vermutlich nicht berücksichtigt.

Also bspw. "Project" als Sub-Type von "Organization", das Schema enthält aber nur "Organization" als type.

Zusammenhang:

• In der FAQ wird "producer" (als nicht vorhandenes Attribut im AMB) empfohlen mit dem Sub-Typ "Project"

Ist die FAQ dahingehend sinnvoll oder hat der use case dann nicht auch Implikationen für das AMB?

[acka47]

schema.org Sub-Types werden bei der Schema-Validierung im AMB vermutlich nicht berücksichtigt.

Nein, das werden sie nicht, obwohl bei den Sub-Typen von sdo:Organization schon einige relevante dabei sind:

More specific Types

• Airline
• Consortium
• Corporation
• EducationalOrganization
• FundingScheme
• GovernmentOrganization
• LibrarySystem
• LocalBusiness
• MedicalOrganization
• NGO
• NewsMediaOrganization
• OnlineBusiness
• PerformingGroup
• PoliticalParty
• Project
• ResearchOrganization
• SearchRescueOrganization
• SportsOrganization
• WorkersUnion*

Da wir bei affiliation.type, creator.type und contributor.type einen String verlangen und keinen Array erlauben, wird auch die Möglichkeit genommen, zusätzlich einen spezifischeren Typ anzugeben. Das ist sicher nicht optimal. Gibt es irgendwo konkreten Bedarf, spezifischere Typen zu verwenden? Dann sollten wir auf jeden Fall mal ein separates Ticket aufmachen.

Zusammenhang:

• In der FAQ wird "producer" (als nicht vorhandenes Attribut im AMB) empfohlen mit dem Sub-Typ "Project"

Ist die FAQ dahingehend sinnvoll oder hat der use case dann nicht auch Implikationen für das AMB?

Die FAQ gibt hier Hinweise, wie bestimmte Informationen repräsentiert werden können, die bisher nicht im AMB abgedeckt sind, was aber nicht klar gesagt wird. Es wäre sicher sinnvoll, in der Antwort klar zu schreiben, dass die Lösung eine schema.org-konforme Lösung ist, die (bisher) nicht im AMB spezifiziert ist.

[oellers]

Gibt es irgendwo konkreten Bedarf, spezifischere Typen zu verwenden? Dann sollten wir auf jeden Fall mal ein separates Ticket aufmachen.

Nur indirekt, da wir Projekte erfassen wollen würden. Da wir aber keine konkreten Attribute aus dem Sub-Typ verwenden, können wir m.E. auch einfach Organization statt dem spezifischeren Typ Project deklarieren.

Statt producer würden wir Stand jetzt vmtl. publisher nutzen, da es producer nicht direkt im AMB gibt. "Veröffentlichung" durch Projekt passt bei uns im Kontext ggf. sogar besser als "Erstellung" durch Projekt. Siehst du dahingehend Bedenken? Vielleicht wäre das auch in der FAQ eine mögliche alternative Empfehlung, um ein bestehendes AMB-Attribut nachzunutzen. Alternative wäre, wir deklarieren es erstmal als producer additiv zum AMB, konform der FAQ, dann könnte man natürlich den Sub-Typ auch nehmen.

Side-Topic
In dem Zuge ist mir aufgefallen, dass affliliation als gleichrangige Listung der Attribute in den HTML Spezifikationen vermutlich missverständlich ist. Wir führen affliliation als Attribut von Bildungsressourcen, definieren es aber wie in schema.org und erwarten es eigentlich nur als Attribut zu einem "Personen"-Objekt, z.B. in creator oder contributor:
https://github.com/dini-ag-kim/amb/blob/main/20231019/schemas/contributor.json#L29, nicht jedoch als Attribut für die Bildungsressourcen. Theoretisch müsste das Attribut auch bei publisher Sinn ergeben, da wir dort auch Personen erwarten, dort fehlt es allerdings.

Falls du in irgendwas davon eine Relevanz siehst, mache ich dazu gerne ein richtiges Ticket auf.

[acka47]

Statt producer würden wir Stand jetzt vmtl. publisher nutzen, da es producer nicht direkt im AMB gibt. "Veröffentlichung" durch Projekt passt bei uns im Kontext ggf. sogar besser als "Erstellung" durch Projekt. Siehst du dahingehend Bedenken?

Nein, ich habe da keine Bedenken.

[acka47]

In dem Zuge ist mir aufgefallen, dass affliliation als gleichrangige Listung der Attribute in den HTML Spezifikationen vermutlich missverständlich ist. Wir führen affliliation als Attribut von Bildungsressourcen, definieren es aber wie in schema.org und erwarten es eigentlich nur als Attribut zu einem "Personen"-Objekt, z.B. in creator oder contributor:
https://github.com/dini-ag-kim/amb/blob/main/20231019/schemas/contributor.json#L29, nicht jedoch als Attribut für die Bildungsressourcen.

Ja, das ist irreführend und es ist tatsächlich die einzige Property, bei der wir so verfahren (z.b. bei provider wäre das dann ja auch möglich/sinnvoll). Nachtrag: Ich nehme an, das ist es auch, was @TobiasNx in #159 meinte.

Theoretisch müsste das Attribut auch bei publisher Sinn ergeben, da wir dort auch Personen erwarten, dort fehlt es allerdings.

Das stimmt.

[acka47]

Im heutigen Treffen besprochen: @oellers macht einen Vorschlag für die AMB-konforme Anpassung der FAQ.