diff --git a/content/posts/2018-09.md b/content/posts/2018-09.md index 4a1cc166b..047c0657f 100644 --- a/content/posts/2018-09.md +++ b/content/posts/2018-09.md @@ -214,4 +214,11 @@ $ sudo docker run --name dspacedb -v dspacetest_data:/var/lib/postgresql/data -e - I told Sisay to run the XML file through tidy - More testing of the access and usage rights changes +## 2018-09-13 + +- Peter was communicating with Altmetric about the OAI mapping issue for item [10568/82810](https://cgspace.cgiar.org/oai/request?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:cgspace.cgiar.org:10568/82810) again +- Altmetric said it was somehow related to the OAI `dateStamp` not getting updated when the mappings changed, but I said that back in [2018-07]({{< relref "2018-07.md" >}}) when this happened it was because the OAI was actually just not reflecting all the item's mappings +- After forcing a complete re-indexing of OAI the mappings were fine +- The `dateStamp` is most probably only updated when the item's metadata changes, not its mappings, so if Altmetric is relying on that we're in a tricky spot +- We need to make sure that our OAI isn't publicizing stale data... I was going to post something on the dspace-tech mailing list, but never did diff --git a/docs/2018-09/index.html b/docs/2018-09/index.html index e55247b80..9c0e9b854 100644 --- a/docs/2018-09/index.html +++ b/docs/2018-09/index.html @@ -18,7 +18,7 @@ I’m testing the new DSpace 5.8 branch in my Ubuntu 18.04 environment and I " /> - + More testing of the access and usage rights changes - +
dateStamp
not getting updated when the mappings changed, but I said that back in 2018-07 when this happened it was because the OAI was actually just not reflecting all the item’s mappingsdateStamp
is most probably only updated when the item’s metadata changes, not its mappings, so if Altmetric is relying on that we’re in a tricky spot