Profil-URI zusammen mit Metadaten angeben

[acka47]

Wir sollten in Abschnitt "3. Format und Bereitstellung" ergänzen, dass zusammen mit den Metadaten ein Link auf das genutzte Profile bzw. die genutzte Version angegeben werden MUSS.

Die Frage ist, wie wir das am besten ausdrücken. Eine fertige Spec für "Profile Negotiation" scheint es noch nicht zu geben, ich finde nur den Entwurf unter https://profilenegotiation.github.io/I-D-Profile-Negotiation/I-D-Profile-Negotiation. (@larsgsvensson, wird es da zukünftig etwas geben?). Im FAIR Signposting Profile ist etwas vom formats attribute die Rede, das hier evtl. benutzt werden könnte. Es gibt aber keine konkreteren Angaben, wie das benutzt werden soll.

Aus Abschnitt 2.1.1. Level 1 - A Minimal Set of Typed Links Pertaining to the Landing Page:

Many other bibliographic formats are in use that have text/plain, application/xml, application/json, or application/json+ld as MIME type. When providing metadata that describes the scholarly object using these MIME types, use the formats attribute on the link to convey, by means of an HTTP URI, the specific format of the metadata. For example, for metadata expressed as application/xml, provide the XML Namespace URI in the formats attribute.

(Wegen dem inkorrekten JSON-LD Mime Type habe ich übrigens schon ein Ticket gemacht.)

[acka47]

Wir sollten auch eine Variante ergänzen, den Link zum genutzten Profil in den Metadaten selbst (passend ist da das mainEntityOfPage-Objekt) angeben zu können.

[larsgsvensson]

@acka47 nach langer Vorlaufzeit habe ich gestern einen I-D für Profile Negotiation an IETF übermittelt und in der httpapi WG gefragt, ob sie den Vorschlag übernehmen wollen. Noch gibt es keine Rückmeldung dazu.

[acka47]

Wir sollten auch eine Variante ergänzen, den Link zum genutzten Profil in den Metadaten selbst (passend ist da das mainEntityOfPage-Objekt) angeben zu können.

schema.org scheint dafür nichts zu haben. Die beste Property dafür ist wohl http://purl.org/dc/terms/conformsTo. Siehe auch https://www.w3.org/TR/dx-prof/#Property:conformsTo.

[acka47]

Es gibt eine publizierte Spezifikation des 'profile' Link Relation Type (RDF 6906). Die bringt uns allerdings nur für den Fall etwas, wenn die Metadaten als eigene Webressource abgelegt sind und wir den HTTP Header dieser Metadatenressource entsprechend anpassen. Das würde dann in dem entsprechenden Abschnitt wie folgt aussehen:

Werden die Metadaten als Webressource unter einer eigenständigen URL angeboten, MUSS der Content-Type Header auf application/ld+json gesetzt werden:

Content-Type: application/ld+json
Link: <https://w3id.org/kim/lrmi-profile/2021mmdd/>; rel="profile"

Da wir eine Lösung auch für die Variante des im HTML eingebetteten JSON-LD suchen, plädiere ich für eine einheitliche Lösung in den JSON-Daten selbst mit dct:conformsTo.

[larsgsvensson]

Es gibt eine publizierte Spezifikation des 'profile' Link Relation Type (RDF 6906). Die bringt uns allerdings nur für den Fall etwas, wenn die Metadaten als eigene Webressource abgelegt sind und wir den HTTP Header dieser Metadatenressource entsprechend anpassen. Das würde dann in dem entsprechenden Abschnitt wie folgt aussehen:

Werden die Metadaten als Webressource unter einer eigenständigen URL angeboten, MUSS der Content-Type Header auf application/ld+json gesetzt werden:

Content-Type: application/ld+json
Link: <https://w3id.org/kim/lrmi-profile/2021mmdd/>; rel="profile"

Das klingt nicht ganz korrekt, denn das hieße ja, dass der Content-Type header immer application/ld+json sein müsste, unabhängig vom Format des Payloads.
Ich würde vorschlagen

Werden die Metadaten als Webressource unter einer eigenständigen URI angeboten, MUSS der Server das Format application/ld+json anbieten, entweder als einziges Datenformat oder über http Content Negotiation.

GET /some/resource HTTP/1.1
Accept: text/turtle;q=1.0, application/ld+json; q=0.8

HTTP/1.1 200 OK
Content-Type: application/ld+json
Vary: Accept

P. S. Der I-D zu Profile Negotiation ist jetzt beim IETF eingereicht.

[acka47]

Danke für deine Rückmeldung, Lars.

Das klingt nicht ganz korrekt, denn das hieße ja, dass der Content-Type header immer application/ld+json sein müsste, unabhängig vom Format des Payloads.

Ich war da wohl etwas unklar. Mir ging es in dem Kontext um die Serverantwort, ich sehe keinen Sinn darin, Content Negotiaion ,zu spezifizieren. Es müsste also konkret heißen:

Werden die Metadaten als Webressource unter einer eigenständigen URL angeboten, MUSS der Content-Type Header auf application/ld+json gesetzt werden:

HTTP/1.1 200 OK
Content-Type: application/ld+json
Link: <https://w3id.org/kim/lrmi-profile/2021mmdd/>; rel="profile"
```"

Prinzipiell wird dieses Metadatenprofil ausschließlich als JSON-LD mittels eines JSON Schemas definiert, siehe den Formatabschnitt im aktuellen Draft: https://dini-ag-kim.github.io/lrmi-profile/draft/#format Von daher ist es legitim, Content Negotiation außen vor zu lassen.

Es geht uns um einen pragmatischen Ansatz, einer Lehr-/Lernressource möglichst leicht strukturierte Daten mitzugeben und nicht um einen vollumfängliche LOD-Ansatz mit Content Negotiation etc. Bisher haben die meisten Beteiligten ohnehin wenig Vorerfahrung mit Linked Data, RDF, Content Negotiation etc., weshalb entsprechende Ergänzungen nur zur Verwirrung beitragen würde. (Ich denke, die Spec wird für viele schon so schwierig genug zu lesen sein.)

[acka47]

@larsgsvensson Übrigens habe ich jetzt ohnehin, den HTTP-Header-Ansatz verworfen und schlage vor, die Referenz zum Profil direkt in die JSON Paylpoad zu packen und zwar mit dct:conformsTo in das mainEntityOfPage-Objekt, in dem sich die Metametadaten befinden, siehe #72.

[larsgsvensson]

@acka47

@larsgsvensson Übrigens habe ich jetzt ohnehin, den HTTP-Header-Ansatz verworfen und schlage vor, die Referenz zum Profil direkt in die JSON Paylpoad zu packen und zwar mit dct:conformsTo in das mainEntityOfPage-Objekt, in dem sich die Metametadaten befinden, siehe #72.

Das hat man davon, wenn man Texte außerhalb ihres Kontexts liest...
Ich verstehe und schätze den Pragmatismus sehr. Das ganze in LOD umzuwandeln (z. B. dann auch mit HTML-Repräsentationen der Metadaten, Conneg, etc.) kann ja dann in eine spätere Stufe dazukommen.

[jneubert]

Habt ihr euch dct:conformsTo schon mal angeschaut?

[acka47]

Habt ihr euch dct:conformsTo schon mal angeschaut?

Ja, siehe meinen Kommentar oben. Es ist sogar ein PR damit offen:

[Ich] schlage vor, die Referenz zum Profil direkt in die JSON Paylpoad zu packen und zwar mit dct:conformsTo in das mainEntityOfPage-Objekt, in dem sich die Metametadaten befinden, siehe #72.

[acka47]

Die gesamte Diskussion hat sich mittlerweile dahingehend verlagert, dass die bisher definierte Praxis zur Angabe von Informationen über die Metadaten selbst ("Metametadaten") zur Debatte gestellt ist. Der offene PR unter #72 sieht ein eigenes JSON-Objekt (unter der Property mainEntityOfPage) vor, in dem alle Metametadaten inklusive eine conformsTo-Angabe enthalten sind:

{
  "id": "https://example.org/oer",
  "mainEntityOfPage":[
    {
      "id":"https://example.org/oer.json",
      "type":"Text",
      "provider":{
        "id":"https://example.org/provider",
        "name":"Example Metadata Provider"
      },
      "dateCreated":"2020-01-01",
      "dateModified":"2020-02-02",
      "conformsTo":"https://w3id.org/kim/lrmi-profile/2021mmdd/"
    }
  ]
}

Diese Praxis und insbesondere die Verwendung von mainEntityOfPage führt offensichtlich zu Verwirrungen. Eine Alternative wäre die Nutzung spezifischer Properties auf der gleichen Ebene wie die Metadaten zur Lernressource selbst. Dafür gibt es ins schema.org bereits sdo:sdPublisher, sdo:sdLicense und sd:sdDatePublished. Damit ließen sich die obigen Daten zum Teil bereits momentan abbilden:

{
  "id":"https://example.org/oer",
  "sdPublisher":{
        "id":"https://example.org/provider",
        "name":"Example Metadata Provider"
  },
  "sdDatePublished":"2020-01-01"
}

Was hier fehlt, weil es die Properties nicht in schema.org gibt:

• sdDateModified
• sdConformsTo

Ich bin derzeit mit beiden Ansätzen nicht 100%ig zufrieden, finde aber die Lösung mit dem extra Objekt/Node für die strukturierten Daten eleganter und flexibler, weil sich damit dann im Prinzip alle schema.org-Properties nutzen lassen, die es für CreativeWork gibt. Von daher plädiere ich gegen die Nutzung der sd-Properties.

Vorschlag

Wir nutzen ein eigenes Objekt, geben es aber nicht mit mainEntityOfPage an, weil das eine ziemlich verwirrende Property ist, sondern nutzen eine neue Property (die wir dann am besten auch für die Ergänzung in schema.org vorschlagen). Die könnte zum Beispiel structuredData heißen:

{
  "id": "https://example.org/oer",
  "structuredData":[
    {
      "id":"https://example.org/oer.json",
      "type":"Text",
      "provider":{
        "id":"https://example.org/provider",
        "name":"Example Metadata Provider"
      },
      "dateCreated":"2020-01-01",
      "dateModified":"2020-02-02",
      "conformsTo":"https://w3id.org/kim/lrmi-profile/2021mmdd/"
    }
  ]
}

[TobiasNx]

Ich finde die Lösung gut und einleuchtend! Ich verstehe nur noch nicht, was mit der type Angabe in structuredData gemeint ist. Btw. in deinem Vorschlag bei schema.org hast du die id der structured-data vergessen.

[acka47]

in deinem Vorschlag bei schema.org hast du die id der structured-data vergessen.

Das habe ich absichtlich gemacht, da es da in der Regel eh keine @id gibt...

[acka47]

Über das schemaorg-Ticket (schemaorg/schemaorg#2887) bin ich jetzt auf ein sehr ähnliches Ticket im bereich Life Sciences aufmerksam geworden:BioSchemas/specifications#297. Die unterstützen unseren Ansatz.

[acka47]

Ich entferne das jetzt mal aus dem Meilenstein Version 1.0. Ich denke, das ist entbehrlich für eine erste Version und eine gute Lösung ist momentan nicht umzusetzen.

[acka47]

Wir sollten das Thema wieder aufgreifen, weil wir ja nun eine erste offiziell publizierte Version haben und damit spätestens jetzt eine Angabe der Profil-URL sinnvoll ist. Da sich in schemaorg/schemaorg#2887 nichts getan hat, sind wir bei mainEntityOfPage geblieben. Wir könnten jetzt conformsTo im Kontext und der Spec ergänzen (am besten als SOLL-Anforderung), damit so etwas ergänzt werden kann und wird:

{
  "id": "https://example.org/oer",
  "mainEntityOfPage":[
    {
      "id":"https://example.org/oer.json",
      "type":"Text",
      "provider":{
        "id":"https://example.org/provider",
        "name":"Example Metadata Provider"
      },
      "dateCreated":"2024-01-01",
      "dateModified":"2024-02-02",
      "conformsTo":"https://w3id.org/kim/amb/20231019/"
    }
  ]
}

[kulla]

Wir könnten jetzt conformsTo im Kontext und der Spec ergänzen (am besten als SOLL-Anforderung), damit so etwas ergänzt werden kann und wird:

Ich wäre dafür, dass es ein Objekt ist, um ggf auch weitere Angaben in Zukunft ohne Breaking Changes machen zu können...