search

dini-ag-kim / amb

A LRMI-/schema.org-based profile for describing educational resources
https://w3id.org/kim/amb/latest/
16 stars 14 forks source link

Erweiterung der erlaubten Vokabulare in `about` #269

Open lummerland opened 5 months ago

lummerland commented 5 months ago

Derzeit sind laut Dokumentation zwei Vokabulare im Feld about möglich zu verwenden: Die Hochschulfächer oder die Schulfächer.

Im Validierungsschema sieht das so aus:

https://github.com/dini-ag-kim/amb/blob/2adf7ca15d18a7e5333b9f8503e8695b8061196a/20231019/schemas/about.json#L32

Es gibt AnbieterInnen von Inhalten (u.A. bspw. im Kontext von Mein Bildungsraum, wo das AMB explizit supported und gefeatured wird), die in anderen Bildungsbereichen unterwegs sind und andere Fächer oder Themen verwenden. Wir sollten uns darüber Gedanken machen, welche Möglichkeiten es für dieses Bedürfnis gäbe und welchen Ansatz wir davon in die Umsetzung bringen wollen.

lummerland commented 5 months ago

In der Gruppe haben wir das andiskutiert (https://metadaten.community/t/mai-treffen-der-metadatengruppe/284/4):

Diskussion:

lummerland commented 5 months ago

@trostorff Wenn ihr eine passende Vokabelliste für euch gefunden habt ist das hier dann sicher euer Thema :)

Arkusm commented 5 months ago

An der Stelle kann ich noch einmal die Diskussion bei e-teaching.org zurückspiegeln.

Wir beschäftigen uns auf der Metaebene mit der Gestaltung von Hochschulbildung mit digitalen Medien, also sowas wie Lehre mit digitalen Medien oder E-Teaching und dort natürlich mit Unterthemen aus dem Bereich Lehrszenarien, Organisation, Didaktik, Technik, .... Aber nicht mal die Metaebene E-Teaching ist in den Fachsystematiken abbildbar. Es handelt sich eben auch um kein Schul- oder Hochschulfach und wir finden es ungünstig, noch nicht mal unser Metathema in einen Attribut was Fach/Thema heißt, abbilden zu können.

Derzeit werden folgende Möglichkeiten diskutiert: a) das Attribut wegzulassen, b) Fachübergreifend zu vergeben oder c) eine neue Systematik in die Diskussion einzubringen.

Bei den Varianten a und b wird darüber hinaus diskutiert, ob das Attribut teaches als Verweis auf Kompetenz(en), die mit Hilfe der beschriebenen Bildungsressource erreicht werden können, nicht stattdessen für eine nähere Beschreibung geeignet wäre. Eine zu erreichende Kompetenz ist zwar etwas anderes als ein Thema, wenn man aber z.B. die Wertelisten aus ESCO (als Kategorisierung von Fähigkeiten, Kompetenzen, Qualifikationen und Berufen) verwendet, kommt man damit viel näher an die Themen, mit denen wir uns beschäftigen. Nachteil hier, teaches sieht keine spezifischen Vokabulare vor. Wenn hier spezifische Vokabulare verwendet werden, wird sich das nicht zwingend maschinenlesbar erschließen, z.B. für Suchmaschinen.

Für c haben wir noch keinen abschließenden Vorschlag.

acka47 commented 5 months ago

@Arkusm b) und c) ließen sich auch gut kombinieren, so dass ihr nicht a) machen müsst. Wenn es sinnvoll ist "Fachübergreifend" zu vergeben, hättet ihr die derzeitige Bedingung des Profils erfüllt:

Mindestens ein JSON-Objekt MUSS für id einen Wert aus [Hochschulfächersystematik] oder [Schulfächerliste] aufweisen.

Wie @lummerland oben schreibt, steht es alllen jetzt schon frei, zusätzlich zu einem Wert aus den gennannten Systematiken Werte aus anderen – standardisierten oder anwendungsspezifischen – Systematiken zu ergänzen.

Arkusm commented 5 months ago

@Arkusm b) und c) ließen sich auch gut kombinieren, so dass ihr nicht a) machen müsst. Wenn es sinnvoll ist "Fachübergreifend" zu vergeben, hättet ihr die derzeitige Bedingung des Profils erfüllt:

Mindestens ein JSON-Objekt MUSS für id einen Wert aus [Hochschulfächersystematik] oder [Schulfächerliste] aufweisen.

Wie @lummerland oben schreibt, steht es alllen jetzt schon frei, zusätzlich zu einem Wert aus den gennannten Systematiken Werte aus anderen – standardisierten oder anwendungsspezifischen – Systematiken zu ergänzen.

Tatsächlich war mir bisher nicht klar, dass eine id aus irgendeiner anderen Systematik genutzt werden darf (obwohl es sich implizit aus dem beschreibenden Text von about ergibt). Mit der Einführung von Fachübergreifend hat das dann auch für uns einen praktischen Nutzen, da man sich vorher für ein Fach oder spezielle Fächer entscheiden musste. Vermutlich haben wir das aus der Zeit vor Fachübergreifend als nicht nutzbar für uns klassifiziert.

Eine Anregung wäre vielleicht noch, dass man zur besseren Zuordnung explizit das Schema angeben können soll, aus dem der Wert kommt, falls es sich nicht schon aus der URI des Wertes selbst schließen lässt. Das wird z.B. mit schemeURI im Rahmen von nameIdentifier im DataCite Metadata Schema gemacht.

acka47 commented 5 months ago

Eine Anregung wäre vielleicht noch, dass man zur besseren Zuordnung explizit das Schema angeben können soll, aus dem der Wert kommt, falls es sich nicht schon aus der URI des Wertes selbst schließen lässt. Das wird z.B. mit schemeURI im Rahmen von nameIdentifier im DataCite Metadata Schema gemacht.

Wir hatten in einer früher Entwurfs-Versionen skos:inScheme drin (siehe z.B. https://github.com/dini-ag-kim/amb/blob/a9b031eda435d39f29a6d6fb1eaa0dd7669a24e5/draft/schemas/about.json), es steht auch noch im AMB-JSON-LD-Kontext. Auch jetzt weisen wir zumindest drauf hin, dass ein SKOS-Konzept benutzt werden solle, siehe die type-Angabe im Schema, es ist aber nicht obligatorisch. Wenn sich die Implementierenden dran halten, lässt sich das Vokabular jeweils durch Resolven der Konzept-ID oder auch bereits durch Inspektion derselben erkennen. Von daher sehe ich da nicht unbedingt den Bedarf. Wir sollten aber wohl unter about klar schreiben, dass es sich nicht bloß um einen "Wert aus einer Vokabelliste" handeln soll, sondern um ein Konzept aus einem SKOS-Vokabular.

acka47 commented 2 months ago

Vorschlag für das weitere Vorgehen. Ich mache eine Ticket hierfür auf:

Wir sollten aber wohl unter about klar schreiben, dass es sich nicht bloß um einen "Wert aus einer Vokabelliste" handeln soll, sondern um ein Konzept aus einem SKOS-Vokabular.

und wir schließen dieses Ticket. Ok?