mainEntityOfPage: Beschreibungstext von type fehlt

[kulla]

In https://dini-ag-kim.github.io/amb/draft/#dfn-mainentityofpage fehlt der Beschreibungstext von type obwohl er in https://w3id.org/kim/amb/draft/schemas/mainEntityOfPage.json vorkommt. Außerdem sollte in https://w3id.org/kim/amb/draft/schemas/mainEntityOfPage.json der Typ von type IMHO auf Array<string> geändert werden -> Also entweder type im JSON Schema löschen oder im Beschreibungstext aufnehmen. Was ist hier das sinnvollste?

[acka47]

Also entweder type im JSON Schema löschen oder im Beschreibungstext aufnehmen. Was ist hier das sinnvollste?

Wenn wir das drin behalten – was ich für sinnvoll halte, weil wir am besten bei allen Objekten eine type-Angabe drin haben sollten –, dann sollten wir uns auch überlegen, welchen Wert wir da vorgeben. (In OERSI gibt es da derzeit keine type-Angabe.)
Evtl. https://schema.org/WebContent als type?

[kulla]

Evtl. https://schema.org/WebContent als type?

Wir benutzen AMB im Rahmen einer GraphQL API (siehe https://lenabi.serlo.org/metadata-api). Hier passt WebContent nicht ganz, aber spontan sehe ich auch keine Alternative. Ich mache mir mal Gedanken...

[kulla]

Im letzten Sprint haben wir den Wert https://schema.org/Dataset entdeckt, der passend ist (siehe #235 ). In einem Gespräch wurde ich auch auf https://schema.org/WebAPI aufmerksam gemacht (siehe #236). Was denkt ihr zu beiden Werten? (ping @acka47 )

[kulla]

Oh, ich stelle gerade fest, dass https://schema.org/WebAPI nicht die properties dateCreated und dateModified aufweist, die nach https://dini-ag-kim.github.io/amb/draft/#dfn-mainentityofpage definiert werden können -> Also lieber nur Dataset vorgeben?

Weitere Frage: Aktuell ist id required. Bei anderen Objekten ist in der Regel nur name und type required. Sollen wir das hier anpassen?

[acka47]

Im letzten Treffen konnten wir uns nicht auf einen spezifischen Typ einigen, siehe https://pad.gwdg.de/s/2023-07-11-kim-oer#Bericht-zu-den-AMB-Sprints-am-226-und-67.

Mittlerweile wurden folgende fünf Vorschläge genannt:

• WebContent: Ist missverständlich, da in vielen Zusammenhang "Content" in "Opposition" zu "Metadaten" verwendet wird und es sich hier aber um ein Metadatendokument handelt. (So angemerkt von @bokahama .)
• Dataset: der Ausdruck steht gängigerweise für eine Sammlung von Datensätzen anstatt für einzelne Beschreibungen (um die es ja in diesem kontext geht. Diese Bedenken wurden im Treffen von mir genannt.)
• WebAPI: Beschreibt eher eine gesamte Web-API samt Endpoint, Parametern, Zugangsbedingungen etc. und nicht einzelne über die API bezogene Informationen. Diesen Typ hatte @kulla mit folgender Begründung ins Spiel gebracht:

  Wir benutzen AMB im Rahmen einer GraphQL API (siehe https://lenabi.serlo.org/metadata-api). Hier passt WebContent nicht ganz, aber spontan sehe ich auch keine Alternative. Ich mache mir mal Gedanken...

  • M.E. ist es aber gleichgültig, ob der Inhalt statisch geliefert oder dynamisch generiert wird, solange eine Web-Ressource (die Beschreibung) unter einer @id/einem Uniform Resource Identifier/Locator ausgeliefert wird.
• Ich hatte im Treffen noch DigitalDocument ins Spiel gebracht.
• CreativeWork: Es waren sich alle einig, dass die Ergänzung eines Typs sinnvoll sei und zur Not eben dieser generische Typ verwendet werden könnte.

[acka47]

@bokahama hat seinen Einwand gegen WebContent zurückgezogen. Wenn es für dich ok ist, @kulla, würde ich das dann damit umsetzen. In Ordnung?

[kulla]

@bokahama hat seinen Einwand gegen WebContent zurückgezogen. Wenn es für dich ok ist, @kulla, würde ich das dann damit umsetzen. In Ordnung?

Sorry, habe vergessen zu antworten: Ja, das passt für mich 😄

[acka47]

Erledigt mit #253 . Closing