One of the challenges that we face in Labs and Research at Crossref is that, as we prototype various tools, we need the community to be able to test them. Often, this involves asking for deposit to a different endpoint or changing the way that a platform works to incorporate a prototype.
The problem is that our community is hugely varied in its technical capacity and level of ability when it comes to modifying their platform.
When each line of code is written it is surrounded by a sea of context: who in the community this is for, what problem we’re trying to solve, what technical assumptions we’re making, what we already tried but didn’t work, how much coffee we’ve had today. All of these have an effect on the software we write.
By the time the next person looks at that code, some of that context will have evaporated.
It turns out that one of the things that is really difficult at Crossref is checking whether a set of Crossref credentials has permission to act on a specific DOI prefix. This is the result of many legacy systems storing various mappings in various different software components, from our Content System through to our CRM. To this end, I wrote a basic application, credcheck, that will allow you to test a Crossref credential against an API.
Subject classifications have been available via the REST API for many years but have not been complete or reliable from the start and will soon be deprecated. dfdfd
The subject metadata element was born out of a Labs experiment intended to enrich the metadata returned via Crossref Metadata Search with All Subject Journal Classification codes from Scopus. This feature was developed when the REST API was still fairly new, and we now recognize that the initial implementation worked its way into the service prematurely.
Following up on his earlier post (which was also blogged to CrossTech here), Leigh Dodds is now [Following up on his earlier post (which was also blogged to CrossTech here), Leigh Dodds is now]3 the possibility of using machine-readable auto-discovery type links for DOIs of the form
These LINK tags are placed in the document HEAD section and could be used by crawlers and agents to recognize the work represented by the current document. This sounds like a great idea and we’d like to hear feedback on it.
Concurrently at Nature we have also been considering how best to mark up in a machine-readable way DOIs appearing within a document page BODY. Current thinking is to do something along the following lines:
which allows the DOI to be presented in the preferred Crossref citation format (doi:10.1038/nprot.2007.43), to be hyperlinked to the handle proxy server (<a href="http://0-dx-doi-org.library.alliant.edu/10.1038/nprot.2007.43">http://0-dx-doi-org.library.alliant.edu/10.1038/nprot.2007.43</a>), and to refer to a validly registered URI form for the DOI (info:doi/10.1038/nprot.2007.43). Again, we would be real interested to hear any opinions on this proposal for inline DOI markup as well as on Leigh’s proposal for document-level DOI markup.
(Oh, and btw many congrats to Leigh on his recent promotion to CTO, Ingenta.)