The turtle and RDF/XML representations seem to be missing several of the metadata attributes, including some which would seem important for machine aggregation, such as rights, citation, isPartOf, and subjects.

Example is here:
http://data.datacite.org/10.5061/DRYAD.17VS2D34/1

It'd be great if this can be fixed.

http://data.datacite.org/10.6096/HYMEX.AROME_WMED.2012.02.20

with schema 3.0 multiple rights can be provided

Documentation:

Creator (PublicationYear): Title. Publisher. Identifier

DataCite Metadata Search Beta:

Creator; (PublicationYear): Title; Publisher. Identifier

Also the documentation describes (optional) display of Version and ResourceType.

The RIS file format is oficially documented to be (for historic reasons, unfortunately) in the windows-1252 character set. The content-resolver returns the text data in UTF-8. This makes it ususeable for citations with umlauts, if you try to import them into Endnote. The same issue exists for Crossref output.

For PANGAEA (where we use the crossref and datacite content negotiation to get full citation information), we use Apache Tika's caracter sets auto-negotiation before parsing the RIS file, but thats not agood idea.

I just opened the issue to hopefully fix this (in communication with Crossref).

it might be irritating if a doi is already registered, but not (yet) in search available

Instead of

{ "issued":  {
  "raw": 2016
}

use

"issued": {
  "date-parts": [
    [
      2016
    ]
  ]
}

For example

AU  - Bräuning, Manuela
AU  - Hellmuth, Markus
AU  - Tumbrink, Theodor

for https://doi.org/10.2314/GBV:731423534

Currently e.g. for contributors the whole text content of the <contributor>; so nameIdentifier is just concatenated to contributorName. The nameIdentifier should also be actionable or at least show schemeURI and/or nameIdentifierScheme.

new in schema 3.0. maybe we should link the rights value if there is a URI given.

Using this content type to return metadata in schema.org/JSON-LD format breaks support for custom application/ld+json media registered with a DOI. See codemeta/codemeta#125 for background.

We should instead use a more specific mime type. This needs more discussion, but for now, we can use application/vnd.schemaorg.ld+json.

it's currently a semi-colon. "and" would be correct.

The Latex escapes a lot of common characters, so importing the BIBTEX files from content-resolver in most cases lead to Latex errors. The rules for escaping characters are very complicated.

At PANGAEA we have an escaper class for BIBTEX that handles most of western chars to be correctly escaped when exported as Latex text (used by BIBTEX). We can provide this Java code here, it should be available to everyone. Its mainly a POJO with a static method that gets a String and returns the String as escaped Latex code.

Due to the template handle on the test prefix 10.5072, a page is rendered for all possible DOI suffixes:

http://data.datacite.org/10.5072/foobardfgdgksdjth

Labels that are too long need to be wrapped so that they do not mask the metadata:

Working on datacite/search#148.

Using the JSON-LD representation of schema.org metadata.

I see that many DataCite services seem to provide DOIs in ALL CAPS. For example, 10.5281/ZENODO.48810 rather than 10.5281/zenodo.48810. I didn't know until now that DOI resolution was case agnostic.

However, I view it as extremely undesirable to transform DOIs from their registered case. Basically, this defies the uniqueness tenant of the DOI system. In other words, I can no longer use DOIs as a primary key for a resource without converting to lowercase myself?

Split given and family name, e.g.

"author": [{
    "family": "Vision",
    "given": "Todd"
}, {
    "family": "Rueda",
    "given": "Laura"
}, {
    "family": "Dasler",
    "given": "Robin"
}, {
    "family": "Haak",
    "given": "Laure"
}, {
    "family": "Cruse",
    "given": "Patricia"
}, {
    "literal": "THOR Consortium"
}]

Instead of returning a 406 error for unknown content types, content negotiation should forward to the URL registered in the handle system, enabling content negotiation at that URL.

See codemeta/codemeta#125 for more details.

It renders Tadi? instead of Tadić as in search

Dear Datacite,
[Feature request:] Would you consider to use utf-8 as standard character set in all citation services?
Or, at least support Accept-Charset / Accept with charset as shown below.

[Bug-report]: For RIS-citations the charset= is doubled in the HTTP response header:

$ curl -v http://data.datacite.org/application/x-research-info-systems/10.21334/npolar.2016.3d72756d -H "Accept: application/x-research-info-systems;charset=utf-8" -H "Accept-Charset:utf-8"

< HTTP/1.1 200 OK
< Content-Type: application/x-research-info-systems; charset=charset=windows-1252

Front conversations

to be consistent with the DataCite Metadata schema

I found this with both text/x-bibliography and text/turtle.

I'm using python-requests; I had trouble making the problem clear using other tools:

> r = requests.get('http://data.datacite.org/10.2312%2FGFZ.syserde.03.01.9', 
         headers={'accept':'text/x-bibliography; style=harvard3'})

No encoding is returned in the response, so according to the HTTP spec the response must be encoded as ISO-8859-1, and that is how it is (incorrectly) decoded.

> r.headers['content-type']
'text/x-bibliography'
> r.encoding
'ISO-8859-1'
> r.text 
u'Cacace,\xc2\xa0Mauro, Scheck-Wenderoth,\xc2\xa0Magdalena, 
Cherubini,\xc2\xa0Yvonne, and Przybycin,\xc2\xa0Anna Maria 2013,
\xe2\x80\x9cBeckenmodellierung: Temperatur in Sedimentbecken,\xe2\x80\x9d
Deutsches GeoForschungsZentrum GFZ, viewed 
<http://dx.doi.org/10.2312/GFZ.syserde.03.01.9>.\n'

Here, \xc2\xa0, \xe2\x80\x9c and \xe2\x80\x9d are all multi-byte UTF-8 characters (nbsp and left/right smartquotes) that have been decoded as multiple single-byte characters.

The correct output can be generated by explicitly decoding as UTF-8, but this is against spec and would require handling this particular service as a special case:

> r.content
'Cacace,\xc2\xa0Mauro, Scheck-Wenderoth,\xc2\xa0Magdalena, 
Cherubini,\xc2\xa0Yvonne, and Przybycin,\xc2\xa0Anna Maria 2013, 
\xe2\x80\x9cBeckenmodellierung: Temperatur in Sedimentbecken,\xe2\x80\x9d 
Deutsches GeoForschungsZentrum GFZ, viewed 
<http://dx.doi.org/10.2312/GFZ.syserde.03.01.9>.\n'
> r.content.decode('UTF8')
u'Cacace,\xa0Mauro, Scheck-Wenderoth,\xa0Magdalena, 
Cherubini,\xa0Yvonne, and Przybycin,\xa0Anna Maria 2013, 
\u201cBeckenmodellierung: Temperatur in Sedimentbecken,\u201d 
Deutsches GeoForschungsZentrum GFZ, viewed 
<http://dx.doi.org/10.2312/GFZ.syserde.03.01.9>.\n'

Currently fields used in the citation are omitted.

java.lang.IllegalStateException: No match found The problematic instruction: ---------- ==> assignment: type=match?groups[1] [on line 150, column 3

To reproduce click: http://test.datacite.org/data/10.5284/1000418

The random UUID in the citation key is not stable, making it impossible to reuse.

https://github.com/datacite/content-resolver/blob/master/src/main/resources/freemarker/doi_bibtex.ftl