dateCreated, datePublished, dateModified – Welche Datumsangaben sind sinnvoll?

[acka47]

Es gibt drei relevante Datumsangaben in schema.org:

• dateCreated
• datePublished
• dateModified

Die Frage ist, welche wir nutzen

1. für die OER selbst,
2. für die Beschreibungsseite/Metadaten (siehe Unterscheide URL für OER und Beschreibungsseite #6)

[acka47]

Derzeit gibt es nur dateCreated für die OER. Eine baldige Ergänzung von datePublished halte ich für sinnvoll.

[mirjan-hoffmann]

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.

[acka47]

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.

[mirjan-hoffmann]

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

[mirjan-hoffmann]

Um nochmal auf die Eingangsfrage zurückzukommen:
dateCreated und dateModified für die Metadaten finde ich ok (so wie derzeit in #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.

[acka47]

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...

[acka47]

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"
  }
}

[acka47]

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.