Open acka47 opened 3 years ago
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.
@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.
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.
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 aufapplication/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
.
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 aufapplication/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.
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 aufapplication/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.)
@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 https://github.com/dini-ag-kim/lrmi-profile/pull/72.
@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 dasmainEntityOfPage
-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.
Habt ihr euch dct:conformsTo schon mal angeschaut?
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 dasmainEntityOfPage
-Objekt, in dem sich die Metametadaten befinden, siehe https://github.com/dini-ag-kim/lrmi-profile/pull/72.
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.
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/"
}
]
}
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.
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...
Über das schemaorg-Ticket (https://github.com/schemaorg/schemaorg/issues/2887) bin ich jetzt auf ein sehr ähnliches Ticket im bereich Life Sciences aufmerksam geworden:https://github.com/BioSchemas/specifications/issues/297. Die unterstützen unseren Ansatz.
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.
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 https://github.com/schemaorg/schemaorg/issues/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",
"structuredData":[
{
"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/"
}
]
}
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...
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:
(Wegen dem inkorrekten JSON-LD Mime Type habe ich übrigens schon ein Ticket gemacht.)