Support update and Multiple
Resolution overview
#crworkshops14
Patricia Feeney
pfeeney@crossref.or
g
Need help?
Help Documentation
http://www.crossref.org/help
Support
http://support.crossref.org and
support@crossref.org
Announcements
 Twitter: crossrefsupport
 http://support.crossref.org/forums/147622-
announcements (subscribe via RSS or email)
New year, new schema
 New Schema versions:
 4.3.4: support for standards
 4.3.5: relationships
<name> <depositor_name>
What Questions?
From members:
How-to, general troubleshooting, new services,
Multiple Resolution, how to deposit non-standard
content types
From users (mostly authors):
Missing authors, order of authors, misspelled
authors, undeposited DOIs, issues with other
metadata
Multiple Resolution
Multiple resolution is simply assigning multiple
URLs to a single DOI.
Sounds
easy!
Easier than
query
matching
CrossR
ef
system
http://dx.doi.org/10.1177/1522162801004001
22
One DOI, 4 URLs, 3 depositors:
 http://www.portico.org/Portico/article?article=pd3qw16ws
 http://triggered.stanford.clockss.org/ServeContent?rft_id=i
nfo:doi/10.1177/152216280100400122
 http://triggered.edina.clockss.org/ServeContent?rft_id=inf
o:doi/10.1177/152216280100400122
 http://resolver.kb.nl/resolve?urn=urn:nbn:nl-
kb:edepot:ewtij:1228472125213
Primary depositor:
 Make friends with secondary
depositors
 Tell CrossRef
 Create interim page template (for
prefix or title)
 Send in deposit plus ‘unlock’ flag
Will you be my
secondary
depositor?
Absolutely!
<doi_data>
<doi>10.50505/mrtest</doi>
<resource>http://www.crossref.org/help/
</resource>
<collection property="list-based" multi-
resolution="unlock" />
</doi_data> Here let me
unlock these DOIs
for you
Thanks!
<head>
<title>Current Links for doi:<!--doi-
-></title>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8" />
<link rel="stylesheet" rev="stylesheet"
type="text/css"
href="/iPage/docs/css/mr.css" />
</head>
. . .
<table width="450">
<!--metadata-->
</table>
<!- - metadata - ->
Metadata – pulled from deposit metadata
<!- -doi-- >
DOI
<!--link-prime-->
URL (<resource>) supplied with primary
deposit
<!- -link label=“xxxxxx”- ->
Secondary URL supplied with label
Template!
<!- -metadata- ->
<!--link-prime-->
<!--link label="CLOCKSS_EDINA"-->
<!--link label="CLOCKSS_SU"-->
<!--link label="KB_fulltext"-->
Secondary depositor
 Create secondary deposit XML
 Send to CrossRef
 Update as needed
You can be the
primary depositor
next time.
I have the
easy job!
<doi_resources>
<doi>10.1177/152216202237621</doi>
<collection property="list-based">
<item label="CLOCKSS_SU">
<resource>http://triggered.stanford
.clockss.org/ServeContent?rft_id=info:do
i/10.1177/152216202237621
</resource>
</item>
</collection>
</doi_resources>
http://dx.doi.org/10.1177/152216280100400122
One DOI, 4 URLs, 3 depositors:
 http://www.portico.org/Portico/article?article=pd3qw16ws
 http://triggered.stanford.clockss.org/ServeContent?rft_id=info:doi/10.1177/15
2216280100400122
 http://triggered.edina.clockss.org/ServeContent?rft_id=info:doi/10.1177/1522
16280100400122
 http://resolver.kb.nl/resolve?urn=urn:nbn:nl-kb:edepot:ewtij:1228472125213
Multiple resolution = assigning multiple URLs to a single DOI
Bypass interim page
Primary URL: ?locatt=mode:legacy
http://dx.doi.org/10.1177/152216280100400301?locatt=mode:legacy
Secondary URL: locatt=label:{label}
http://dx.doi.org/10.1177/152216280100400301?locatt=label:CLOCKSS_
EDINA

2014 CrossRef Workshops: Support Update and Multiple Resolution Overview

Editor's Notes

  • #3 Where to go for help New twitter account for support only, will post outages, new schema versions, etc.
  • #4 We’ve incremented the schema twice in the past year, for Schema version 4.3.4, the most substantial revision is to support of standards, we added a ‘standard designator’ field along with some other changes, modifications are ongoing, we have a technical working group for standards that is very actively making changes. 4.3.5 was just released last week and supports relationships between DOIs It’s important to note that 4.3.4 and 4.3.5 are not 100% backwards compatible, we’ve decided to use the element ‘name’ for author names in the future, and have changed ‘name’ in the depositor information section to ‘depositor name’ aside from that it’s backwards compatible unless you are depositing standards. We are adding a lot to the schema as far as relationships, text and data mining, crossmark, fundref, etc. and might be removing support for older versions in the future, so if you are able you might want to migrate now.
  • #5 We continue to have a very busy support queue, most requests are routine but some can be interesting. We’ve seen a big increase in tickets from end users in the past few years, CrossRef metadata is much more visible because of things like integrating with ORCID, and people are finding us to report errors. We’ve also had an increased interest in multiple resolution for both books and journals. I’m going to go over multiple resolution as it exists now, Mike is going to introduce our new co-access solution for books.
  • #6 As you probably know, we want only a single DOI to exist for an item wherever possible, but situations arise where content lives in multiple locations. Multiple resolution is simply assigning multiple URLs to a single DOI. It’s simple conceptually but there’s some coordination that needs to happen for it to work
  • #7 This is an example of a mult. Res. DOI, in this case this is a ‘triggered title’ meaning this title has ceased publication, hosting of the existing content has been taken over by a few archiving organizations. This DOI has 4 URLs attached to it, instead of resolving directly to the content, it resolves to an interim page with all 4 links.
  • #8 So how does this happen? For multiple resolution, there is one ‘primary’ depositor and at least one secondary depositor. The primary depositor is the owner of the prefix of the MR DOIs, so they’re able to do everything, I’ll go into more detail in a minute ‘Secondary’ depositors: Can only add URLs to a DOI, can’t update metadata or unlock DOIs In most cases require a special multiple resolution deposit account.
  • #9 So how does this happen? For multiple resolution, there is one ‘primary’ depositor and at least one secondary depositor. The ‘primary’ depositor deposits the multiple resolution DOI, this is a normal metadata deposit, only the primary depositor is able to create a DOI and deposit or update metadata for the DOI. Once a member has decided that they want to allow multiple resolution for their DOIs, they need to contact CrossRef so that we can set up any necessary permissions for secondary depositors. The Primary dep. Also usually create an interim page template, and unlock DOIs, meaning they flag a DOI as being multiple resolution enabled. Your deposit accounts are mr enabled by default. Multiple resolution permissions are enabled at the prefix level, the interim pages can be assigned at the title level. We can have two ‘primary’ depositors assigned to a prefix, this is a ‘proceed with caution’ situation, in the past this almost always results in overwritten data or duplication of DOIs.
  • #10 One ‘primary’ depositor: metadata deposit (includes a URL), flags DOIs as multiple-resolution ready (‘unlock’). Your regular deposit account is a primary mr deposit account by default. ‘Secondary’ depositors: Can only add URLs, can’t update metadata or unlock DOIs Requires a multiple resolution deposit account. We can have two ‘primary’ depositors assigned to a prefix, this is a ‘proceed with caution’ situation, in the past this almost always results in overwritten data or duplication of DOIs.
  • #11 Template: HTML page, can include CSS, javascript, whatevs, most of the page is static but certain fields are populated with MR data, in this example: <!—metadata <!—label etc. <!--link label="CLOCKSS_EDINA"--> <!--link label="KB_fulltext"-->
  • #12 Template: HTML page, can include CSS, javascript, whatevs, most of the page is static but certain fields are populated with MR data, in this example: <!—metadata <!—label etc. <!--link label="CLOCKSS_EDINA"--> <!--link label="KB_fulltext"-->
  • #13 Template: HTML page, can include CSS, javascript, whatevs, most of the page is static but certain fields are populated with MR data, in this example: <!—metadata <!—label etc. <!--link label="CLOCKSS_EDINA"--> <!--link label="KB_fulltext"-->
  • #14 Secondary depositors create multiple resolution URL deposits, no metadata is included – sec. dep. an only add URLs, can’t update metadata or unlock DOIs. We create special multiple resolution-only accounts for secondary depositors. Permissions are established at the prefix level, a secondary depositor is only able to add or update secondary URLs to a DOI for which they have prefix-level permissions, they also can only update unlocked DOIs, they aren’t able to unlock DOIs themselves.. We can have two ‘primary’ depositors assigned to a prefix, this is a ‘proceed with extreme caution’ situation as both depositors are able to create DOIs and update metadata, in the past this almost always results in overwritten data or duplication of DOIs. A primary depositor can also add secondary URLs, in this case you don’t need to contact us to finagle permissions, you only need to supply us with an interim page and unlock the DOIs.
  • #15 Here’s a snippet from a secondary deposit, it contains the DOI, a label, and the URL associated with that label.
  • #16 The URL associated with the CLOCKSS_SU label is included in the interim page
  • #17 We manage the interim page and permissions, but the multiple resolution is made possible by the Handle resolver, each multiple resolution relationship is also recorded in the resolver record. The label and the URL are included, instead of resolving to the URLs, the DOI resolves to the interim page URL hosted by CrossRef.
  • #18 This allows you to bypass the MR process, you can use the labels supplied in your deposit to create a DOI link with a location parameter, this instructs the resolver to ignore the MR status and resolve directly to the URL associated with the label, the primary URL doesn’t have a label, it defaults to mode:legacy as you see here.