Empfehlung für die Erstellungen von lokalen Profil-Erweiterungen ergänzen

[acka47]

Das LRMI-Profil wird bereits im OERSI-Projekt erweitert und angepasst (siehe dazu z.B. https://gitlab.com/oersi/oersi-etl/-/issues/51) aber auch im ComeIn-Projekt wird es voraussichtlich – wie im heutigen Treffen besprochen – fächerspezifische Erweiterungen geben.

Neben dem Deklarieren des Profils in Instanzmetadaten (#63) wäre wünschenswert, wenn Erweiterungen des Profils ihre Verbindung zum Ursprungsschema irgendwie dokumentieren würden. Hier einige mögliche Ansätze:

1. git-basiert: "Sub-Profile" sind GitHub Forks oder git clones vom Hauptschema und Beziehungen sowie Abweichungen sind über die git History dokumentiert.
2. JSON-basiert: Im Profil selbst wird die Art der Beziehung zum Hauptprofil angegeben. Dafür gibt es in JSON Schema allerdings noch keine gängige Praxis.

Natürlich ist auch die Kombination von 1.) und 2.) möglich. Ich denke, wir sollten hier aber nur einen metadatenbasierten Ansatz (2.) spezifizieren. Ich könnte mir folgendes vorstellen, weiß aber nicht, wann dafür alle Voraussetzungen erfüllt sind.

• JSON Schemas werden als RDF/JSON-LD publiziert, dafür gibt es bereits einen Spec-Entwurf beim W3C: https://www.w3.org/2019/wot/json-schema
• Danach ließe sich mit derProperty prof:isProfileOf aus dem Profiles Vocabulary die Beziehung zum übergeordneten Profil ergänzen.

Das Problem: Sowohl "JSON Schema in RDF" als auch das "Profiles Vocabulary" sind nur in Entwurfsfassung verfügbar, und es ist unklar, ob sie in der Form schon benutzt werden sollten und ob/wann sie offizielle W3C Empfehlungen werden.

[acka47]

Ich denke, wir sollten diesen Punkt aus der ersten offiziellen Version der Spezifikation herauslassen, weil eben die Spezifikationen, die wir für unsere Zwecke nutzen könnten, noch im Entwurfsstatus sind (siehe den vorherigen Kommentar). Außerdem bringt diese Anforderung eine ganz neue Ebene in die Spezifikation, indem eben über Folgeprofile und nicht mehr über Ressourcenmetadaten gesprochen wird. Das zu intergrieren wäre eine größere Herausforderung. Insgesamt übertrifft hier der Aufwand den zu erwartenden Nutzen, weshalb ich das Ticket aus dem meilenstein herausnehme.