Add datestamp

[rettinghaus]

There's no way of knowing how old the presented data is.
I would be good to add a timestamp somewhere in the footer (Datenquellen) to see when it was last updated.

[rettinghaus]

To be more precise: Show when the RDF was received/cached/processed by lobid and when the data itself was modified last (dcterms:modified).

[acka47]

Thanks for the request. I assume your inquiry is referring to the HTML view of a resource. Generally, nearly every entry has a modification date in the JSON in field describedBy.dateModified, e.g. for https://lobid.org/gnd/118903489 it looks like this:

"describedBy":{
    "id":"http://d-nb.info/gnd/118903489/about",
    "license":{
        "id":"http://creativecommons.org/publicdomain/zero/1.0/",
        "label":"http://creativecommons.org/publicdomain/zero/1.0/"
    },
    "dateModified":"2016-10-14T16:01:36.000"
}

The thing is, that this date is pulled from the underlying MARC/Pica record and thus refers to modifications in this record. This means that sometimes

1. the date is adjusted while actually no changes occured in the RDF or
2. the RDF changes but the date is not adjusted.

Would you like us to show the date in the HTML view anyways?

[rettinghaus]

Nonetheless, I think it would be good to show the date in the HTML, even if it's meaningfulness is limited. You can't see it anywhere else (unless you crawl through the raw data). Perhaps some sort of disclaimer could/should be added?

[fsteeg]

Deployed to test, see e.g. https://test.lobid.org/gnd/118903489 (below the table, shortened to the day).

[acka47]

I think the place ("Datenquellen") is the right one to add the information but the current solution is confusing for two reasons:

1. The date seems to refer to both DNB LDS data and EntityFacts or – as it is nearer to the second – only to EntityFacts
2. It is not clear what the date is about.

We should

• either clearly associate the date only with the DNB LDS part
• or add another date for the version of the EntityFacts data that we are using.

I prefer the second solution which would in fact be quite good for ourselves as well. But this would mean that we make describedBy an array and add another object for the underlying EntityFacts data (which we have #294 for).

[fsteeg]

Yes, makes sense. I tried moving the date to associate it with the DNB LDS, but it keeps being confusing, not just due to the 'it's the MARC, not the RDF modification date' from #244 (comment) and the EntityFacts issue above, but we should probably also display the date of our latest updates somehow, like "Mit Updates von 2022-10-11 zuletzt aktualisiert 2016-10-14 im Katalog der DNB und 2020-05-10 in EntityFacts".

(Reverted displaying the date & deployed to test, this stays in backlog, can be implemented after #294.)