Task #3917
Updated by Skye Roseboom over 11 years ago
Similar to issue documented here: https://redmine.dataone.org/issues/3854#note-4
Dryad's ORE seem to define science metadata identifiers that do not exist for the 'dryadDataPackage' files:
Example:
ORE uses '&' in the sci-metadata's identifer - lines 6,24,28,30
http://dev.datadryad.org/mn/object/http://dx.doi.org/10.5061/dryad.8570?format=d1rem&ver=2011-09-02T16:12:04.933-0400
line 30:
<dcterms:identifier rdf:datatype="http://www.w3.org/2001/XMLSchema#string">http://dx.doi.org/10.5061/dryad.8570&ver=2011-09-02T16:12:04.933-0400</dcterms:identifier>
Although dryad meta and object paths respond to both versions of the identifier (one with '&' and one with '?'):
https://dev.datadryad.org/mn/meta/http://dx.doi.org/10.5061/dryad.8570&ver=2011-09-02T16:12:04.933-0400
https://dev.datadryad.org/mn/meta/http://dx.doi.org/10.5061/dryad.8570?ver=2011-09-02T16:12:04.933-0400
It appears only the '?' version is provided via the object list service: (search for 'dryad.8570')
https://dev.datadryad.org/mn/object/?formatId=http://datadryad.org/profile/v3.1&count=100&start=400
Corroborated by the CN - the '?' (%3F) version exists, the '&' '&' version (%26) does not:
https://cn-dev-unm-1.test.dataone.org/cn/v1/meta/http://dx.doi.org/10.5061/dryad.8570%3Fver=2011-09-02T16:12:04.933-0400
https://cn-dev-unm-1.test.dataone.org/cn/v1/meta/http://dx.doi.org/10.5061/dryad.8570%26ver=2011-09-02T16:12:04.933-0400
So it would seem the ORE is using the wrong identifier. This ultimately prevents the CN indexing process from properly indexing the data package.
Dryad's ORE seem to define science metadata identifiers that do not exist for the 'dryadDataPackage' files:
Example:
ORE uses '&' in the sci-metadata's identifer - lines 6,24,28,30
http://dev.datadryad.org/mn/object/http://dx.doi.org/10.5061/dryad.8570?format=d1rem&ver=2011-09-02T16:12:04.933-0400
line 30:
<dcterms:identifier rdf:datatype="http://www.w3.org/2001/XMLSchema#string">http://dx.doi.org/10.5061/dryad.8570&ver=2011-09-02T16:12:04.933-0400</dcterms:identifier>
Although dryad meta and object paths respond to both versions of the identifier (one with '&' and one with '?'):
https://dev.datadryad.org/mn/meta/http://dx.doi.org/10.5061/dryad.8570&ver=2011-09-02T16:12:04.933-0400
https://dev.datadryad.org/mn/meta/http://dx.doi.org/10.5061/dryad.8570?ver=2011-09-02T16:12:04.933-0400
It appears only the '?' version is provided via the object list service: (search for 'dryad.8570')
https://dev.datadryad.org/mn/object/?formatId=http://datadryad.org/profile/v3.1&count=100&start=400
Corroborated by the CN - the '?' (%3F) version exists, the '&' '&' version (%26) does not:
https://cn-dev-unm-1.test.dataone.org/cn/v1/meta/http://dx.doi.org/10.5061/dryad.8570%3Fver=2011-09-02T16:12:04.933-0400
https://cn-dev-unm-1.test.dataone.org/cn/v1/meta/http://dx.doi.org/10.5061/dryad.8570%26ver=2011-09-02T16:12:04.933-0400
So it would seem the ORE is using the wrong identifier. This ultimately prevents the CN indexing process from properly indexing the data package.
