Closed acka47 closed 4 years ago
Derzeit gibt es nur dateCreated
für die OER. Eine baldige Ergänzung von datePublished
halte ich für sinnvoll.
Das klingt gut. Zu dem Ergebnis (datePublished
hinzufügen) bin ich neulich auch mit @axel-klinger gekommen. Die Dringlichkeit für dateModified
ist nicht so hoch, da es derzeit auch schwer zuverlässig ermittelt werden kann.
Für die Diskussion hier noch ein problematisches Beispiel aus EduSharing (JSON stammt aus dem Quelltext von https://www.oerbw.de/edu-sharing/components/render/3ee9fc0a-cda8-424b-ae8c-7a9a2384256a):
{
"identifier": "3ee9fc0a-cda8-424b-ae8c-7a9a2384256a",
"creator": {
"@type": "Person",
"givenName": "Tamara",
"familyName": "Mansaray"
},
"keywords": [
"Civil Engineering",
"Bending Test",
"Forces"
],
"@type": [
"CreativeWork",
"MediaObject"
],
"description": "Localized large deformations occur in a beam made from relatively soft material. Obviously, such behavior cannot be described by linear models",
"inLanguage": "en",
"dateModified": "2020-03-25T17:30:49+01:00",
"@context": "http://schema.org/",
"version": "1.3",
"url": "https://uni-tuebingen.oerbw.de/edu-sharing/components/render/3ee9fc0a-cda8-424b-ae8c-7a9a2384256a",
"license": "https://creativecommons.org/licenses/by/4.0/deed.en",
"dateCreated": "2020-03-04T15:57:33+01:00",
"name": "Three-Point Bending Test on Beam \u2013 Soft Material",
"publisher": {
"legalName": "Institut für angewandte Mechanik RWTH Aachen University (IFAM)",
"@type": "Organization"
},
"learningResourceType": "Video",
"thumbnailUrl": "https://uni-tuebingen.oerbw.de/edu-sharing/preview?nodeId=3ee9fc0a-cda8-424b-ae8c-7a9a2384256a&storeProtocol=workspace&storeId=SpacesStore&dontcache=1589960830560"
}
dateCreated
und dateModified
beziehen sich hier offensichtlich auf die Metadaten, obwohl sie neben Informationen zur OER stehen. Für die OER selbst wird offenbar kein Datum angegeben (publiziert wurde das beschriebene Video auf YouTube am 25.01.2017). Interessant im Kontext von #6: Die URL/id der beschriebenen OER, d.h. der Link zu YouTube, fehlt komplett.
Ja, das ist ein Problem mit verlinktem Material in edu-sharing. Dass das dateCreated
auch nur für die Metadaten gilt, hatte ich aber gerade nicht auf dem Schirm.
Ich sehe ein problematisches Beispiel aus edu-sharing aber auch nicht als Grund hier das Konzept zu ändern. Wenn dateCreated
und dateModified
neben Informationen zur OER stehen, dann sollten auch diese Felder zur OER gehören. Ich würde dann eher versuchen dies in edu-sharing zu fixen oder bei Konvertierungen aus edu-sharing zu berücksichtigen (und zB auf mainEntityOfPage.date
zu mappen).
Wenn man Quellen hat wo die URL der OER nicht verfügbar ist, dann muss man wohl auf einen Workaround zurückgreifen und dort die verfügbare URL (in diesem Fall die URL der Metadaten) verwenden. Den Ansatz URL der OER und URL der Metadaten zu trennen halte ich aber schon für sinnvoll. Evtl kann man den Vorschlag ja auch in edu-sharing einbringen.
Allerdings ist die URL der OER aber schon abrufbar über die Rest API:
curl -X GET --header 'Accept: application/json' 'https://www.oerbw.de/edu-sharing/rest/rendering/v1/details/-home-/3ee9fc0a-cda8-424b-ae8c-7a9a2384256a'
=>
...
"ccm:wwwurl": [
"https://youtu.be/Y7UbOz1WA0A"
],
...
Über OAI fehlt die URL der OER auch wieder:
https://www.oerbw.de/edu-sharing/eduservlet/oai/provider?verb=GetRecord&identifier=3ee9fc0a-cda8-424b-ae8c-7a9a2384256a&metadataPrefix=lom
Um nochmal auf die Eingangsfrage zurückzukommen:
dateCreated
und dateModified
für die Metadaten finde ich ok (so wie derzeit in https://github.com/dini-ag-kim/lrmi-profile/pull/7) Wobei ich auch glaube, dass die Datumsfelder für die Metadaten nur wenig interessant sind. Aber gut, es mag Anwendungsfälle geben bei denen man wissen möchte, ob die Metadaten aktualisiert wurden.
Ich sehe ein problematisches Beispiel aus edu-sharing aber auch nicht als Grund hier das Konzept zu ändern. Wenn dateCreated und dateModified neben Informationen zur OER stehen, dann sollten auch diese Felder zur OER gehören. Ich würde dann eher versuchen dies in edu-sharing zu fixen oder bei Konvertierungen aus edu-sharing zu berücksichtigen (und zB auf mainEntityOfPage.date zu mappen).
Ich gebe dir völlig Recht und sehe, dass ich meine Intention nicht klar genug zum Ausdruck gebracht habe. Ich will natürlich keine problematischen Konzepte übernehmen, nur weil sie da draußen existieren. Stattdessen möchte ich mit diesem Standardisierungsansatz die Anzahl mäßig modellierten OER-Metadaten im Web verringern. Ich gehe also davon aus, dass das Ergebnis unserer Standardisierungsbestrebungen u.a. EduSharing als Vorlage dienen wird, um die eigenen Metadaten zu verbessern.
Wenn man Quellen hat wo die URL der OER nicht verfügbar ist, dann muss man wohl auf einen Workaround zurückgreifen und dort die verfügbare URL (in diesem Fall die URL der Metadaten) verwenden. Den Ansatz URL der OER und URL der Metadaten zu trennen halte ich aber schon für sinnvoll. Evtl kann man den Vorschlag ja auch in edu-sharing einbringen.
Genau. In den EduSharing-Metadaten sollte auf jeden Fall die URL der beschriebenen Ressource enthalten sein und Datumsangaben zu den Metadaten von jenen zur Ressource unterschieden werden. Das sollte dort ja auch leicht umzusetzen sein...
Wobei ich auch glaube, dass die Datumsfelder für die Metadaten nur wenig interessant sind. Aber gut, es mag Anwendungsfälle geben bei denen man wissen möchte, ob die Metadaten aktualisiert wurden.
Ich finde es nur wichtig, die Option offen zu halten, Metametadaten anzuhängen, weshalb wir auf jeden Fall bei mainEntityOfPage
ein Objekt erwarten sollten. Dann haben wir da für die Zukunft maximale Flexibilität.
Zum Beispiel könnte es sein, dass wir in OERSI künftig Provenienzangaben zu den generierten Metadaten ergänzen wollen. Im mainEntityOfPage
-Objekt könnten wir – z.B. unter Nutzung der PROV-Ontologie – angeben, mit welchem Prozess, von welchem Akteur angestoßen Metadaten erzeugt wurden. Wir machen das in lobid-resources, wo wir statt schema:mainEntityOfPage
wdrs:describedby
benutzen. Wir machen dort einige Angaben zum ETL-Prozess (CreateAction
): wann die Metadaten per ETL erzeugt wurden (endTime
), mit welcher Software (instrument
), auf Basis welcher Quelldaten (object
). Außerdem geben wir die Lizenz für die Metadaten an (license
). Ein Beispiel (Snippet):
{
"@context":"http://lobid.org/resources/context.jsonld",
"id":"http://lobid.org/resources/HT002948556#!",
"describedBy":{
"id":"http://lobid.org/resources/HT002948556",
"type":[
"BibliographicDescription"
],
"resultOf":{
"type":[
"CreateAction"
],
"endTime":"2020-05-17T02:07:30",
"instrument":{
"id":"https://github.com/hbz/lobid-resources",
"type":[
"SoftwareApplication"
],
"label":"Software lobid-resources"
},
"object":{
"id":"http://lobid.org/hbz01/HT002948556",
"type":[
"DataFeedItem"
],
"inDataset":{
"id":"https://datahub.io/dataset/hbz_unioncatalog",
"label":"hbz_unioncatalog"
},
"label":"hbz-Ressource HT002948556 im Exportformat MAB2-XML"
}
},
"license":[
{
"id":"http://creativecommons.org/publicdomain/zero/1.0",
"label":"Creative Commons-Lizenz CC0 1.0 Universal"
}
],
"sourceOrganization":{
"id":"http://lobid.org/organisations/DE-464#!",
"label":"lobid Organisation"
},
"label":"Webseite der hbz-Ressource HT002948556"
}
}
Wir haben nun dateCreated
für die Ressourcenbeschreibung (https://github.com/dini-ag-kim/lrmi-profile/blob/ee53cb9b6c343de07b7aa109a5318e2ab220d922/draft/schemas/schema.json#L149-L156) und dateCreated
plus dateModified
für die Metadaten. Ich denke, damit können wir die Diskussion erstmal beenden und das Ticket schließen.
Was datePublished
angeht, sollten wir das ergänzen (in einem separaten Ticket), sobald jemand das wirklich nutzen möchte.
Es gibt drei relevante Datumsangaben in schema.org:
dateCreated
datePublished
dateModified
Die Frage ist, welche wir nutzen