 |
|
 |
|||||||||||||
|
|
 |
|||||||||||||
|
|
(updated September 19, 2007)
Frequently asked questions about using CrossRef
Considerations for DSpace repositories CrossRef encourages organizations which operate institutional repositories to assign DOIs to their original non-duplicative There are a few simple guidelines when the repository is a DSpace based system (www.dspace.org). DSpace and the DOI In order to assign DOIs to DSpace items the repository must join CrossRef and be given a DOI prefix. Subsequently each item
The URL assigned to the DOI should use the form http://hdl.handle.net/DSpace-prefix/DSpace-suffix
CrossRef title records and ISSNs When DOIs are deposited, the CrossRef system must assign the DOI to an internal title record. This is necessary to support The need to do this results from a scale problem. By tracking titles as records the CrossRef system has 14,000 or so items to Since mid 2002 when the system was deployed this situation has had the following consequence. The ISSNs returned in a query http://doi.crossref.org/servlet/query?usr=<usr>&pwd=<pwd>&type=q&format=unixref&qdata=|Physical+Review+B|
What can a DOI be assigned to? CrossRef enables DOI assignment for the following content items:
NOTE: DOIs are required for journal articles, conference papers and book titles but are optional for journal titles, volumes CrossRef is currently working on expanding the types of content it registers DOIs for to include theses and dissertations and
Depositing "As-Crawled" URLs to support metadata distribution to search engines. CrossRef initiatives related to full text indexing of member content by various search engine has taken two forms. 1) CrossRef Search where a sub-group of CrossRef members had their content indexed and then offered through a site 2) Site-maps: these tools provide guidance and aid to search engines to help verify the metadata extracted by the engine These two items are separate and distinct. Publishers may have CrossRef perform #2 on their behalf while not participating in A major problem arose with #2 above when it became known that search engines were crawling publisher’s sites using To rectify this, a recommendation was made at the Google Scholar Publisher Open House (Sept 14th) to allow publishers to This capability is now available in the CrossRef system. It utilizes the <collection> element of the existing schema. Here is an … other article metadata … <doi_data> The <doi_data> element is the same one being used now to deposit the URL bound to the DOI. This happens in the <doi> and In the example above type 'xref:url:crawled:blort' would cause an error. If the same URL is used by more than one search engine, multiple names may by included on one property type value: Depositing crawled URLs by themselves. <?xml version="1.0" encoding="utf-8"?>
DOI Ownership transfer Please see the full details on CrossRef's DOI Ownership Transfer Policies and how to go about initiating a transfer.
Dealing with conflicts
Omitting one or more fields in a deposit increases the chance of a conflict. Conflicts are created for a variety of reasons both intentionally and by mistake. It is the mistakes that the system are trying to ConfID: 1686 CauseID: 15569075 OtherID: 1158478, JT: Macromolecular Chemistry and Physics MD: Koopmann, 199 ,10,2119,1998,Synthesis and properties of poly(dimethyldiphenylsilylenemethylene) DOI: 10.1002/(SICI)1521-3935(19981001)199:10<& DOI: 10.1002/macp.1998.021991007 (1686-null )="=========================================="
Each conflict has a unique ID (confID) and typically involves two DOIs. The deposit submission of the DOI causing the conflict is identified in the CauseID field, while the deposit submission of the effected DOI is listed as the OtherID. The journal title is listed on the line labeled JT and the metadata for the DOIs is shown on the line labeled MD. Since this is a conflict the metadata for both DOIs is the same. The parenthetical value following the DOI (e.g. 1686-null) lists all the conflicts this DOI is involved in and the resolution status of that conflict. Null means the conflict is unresolved. Summary, to correct a conflict: a) redeposit one of the DOIs with new (different) metadata and the conflict will automatically be erased b) contact CrossRef and instruct us to delete conflict #ConfID c) contact CrossRef and instruct us to make one of the DOIs in conflict #ConfID 'prime' Note: while at the moment a CrossRef administrator must get involved to complete options b or c, our plans are to change the system to let users take this action for themselves. Deleting a DOI DOIs are supposed to be persistent and are therefore very difficult to delete. In fact the CrossRef system has no "delete a DOI" function (note: DOIs can be deleted from the Handle system under very specific conditions). Instead of deleting a DOI we recommend updating it to point to an explanatory page describing why the DOI is no longer available. As a default CrossRef maintains a page for these purposes (http://www.crossref.org/deleted_DOI.html). After setting the URL for a DOI to this or a similar page the journal title for the DOI may be updated to "CrossRef Listing Of Deleted DOIs" and the ownership transferred to CrossRef. The DOI then will not be listed on any of the normal CrossRef reports. Note: When making an XML deposit using the above title for the journal please set any ISSN values to 00000000. Also, until the ownership transfer takes place this title will appear in the Depositor Report under your publisher name. An alternative method of deleting DOIs requires the involvement of a CrossRef administrator. This process entails creating two transfer files which the administrator must process. File 1: This file transfers the listed DOIs to the 'journal' CrossRef Listing Of Deleted DOIs. H: email=support@crossref.org;type=transfer_title;toJournal=52144 10.1553/wzksXLVIIs43 10.1553/wzksXLVIIs51 10.1553/wzksXLVIIs105 File 2: This file transfers ownership of the DOIs and points them at the deleted DOI info page H:email=ckoscher@crossref.org;fromPrefix=10.1093;toPrefix=10.5555 10.1553/wzksXLVIIs43 http://www.crossref.org/deleted_DOI.html 10.1553/wzksXLVIIs51 http://www.crossref.org/deleted_DOI.html 10.1553/wzksXLVIIs105 http://www.crossref.org/deleted_DOI.html ... Special characters in deposits and queries Special characters are those that are not part of the ASCII or ISO 8859-1 (Latin-1) character sets. ASCII and Latin-1 characters can be represented in one octet (byte) of information and are displayed properly in almost all editors and viewers on most computer systems. Special characters go beyond this set and are best represented as Unicode characters. Information about Unicode is available at the Unicode Project home page, which has links to some nice tools and resources and a very nice interactive code chart Another interesting chart tool is available here. Unicode is a 16 bit (two octet) format and requires viewers and editors that understand the format to allow users to work with these characters. If you view a Unicode character set file in a non-Unicode viewer you'll likely see a lot of gibberish (little square boxes and question marks). To further complicate things UTF-8 is an encoding scheme that allow Unicode characters to be included in single octet format files, like XML files. Again, you need a UTF-8 capable viewer to work with these types of files. The XML used to make deposits to CrossRef are encoded using UTF-8 (<?xml version="1.0" encoding="UTF-8"?>). Fortunately the ASCII and Latin-1 sets map directly into UTF-8 so that any ASCII file can be viewed and edited in a UTF-8 compliant application (like a browser). The tricky part comes when we want to include a special Unicode character in an XML CrossRef deposit. There are two ways to achieve this:1) Use a UTF-8 editor or tool when creating the XML and just insert characters right in the file (this results in a one or more byte sequence per character appearing in the file)2) Encode the special character using what is called a numerical representation Option #1 would be very easy to do if you've got the right tools. The character shown below has a decimal value of 352 which is 160hex. This converts to the UTF-8 sequence C5,A0 (in hex). A small XML file was created with this 2 byte sequence inserted in between the <UTF_encoded> tags. You'll see that this displays properly in a browser, but if you save the XML source and try to view it in certain editors it will not display correctly (it does display Ok in NotePad). Option #2 is the more common approach and is done by constructing an entity reference in the XML that is the numerical value of the character. Example:<surname>Šumbera</surname> includes the special character  This character was also included as an entity reference in the small XML file mentioned above. Notice that(most) browsers automatically convert the entity reference to the character's actual representation. Resolving problems with a DOI Issues will either result from depositing DOIs, querying for DOIs or following links built with DOIs. Each represent a step in the life-cycle of a DOI and the systems involved in each step are unique. Generally, solutions are not very complicated, there is just a bit of detective work required to figure things out. Dealing with problems is best handled by contacting support@crossref.org. Please provide as much information about the problem as you can. Of particular importance are the submission IDs for deposits and the location of bad DOI links. Using parameter passing Parameter passing is a feature that allows data placed on an outbound DOI link to be passed along to the target publisher. In fact, there are two different procedures. The first utilizes an undocumented feature of the DOI resolver while the second is a robust implementation based on OpenURL structured to prevent name collisions that would result in the loss of data. Procedure #1 For very limited situations where parameter passing is needed the name-value pair called "urlappend" may be used. Outbound links are constructed with parameter values being placed into this single URL variable. However, before constructing the link we must know if the registered URL for the DOI already has parameters. Example:DOI 10.5555/unique_doi_060103-02| has no parameters on its registered URL, passed parameter are added as follows: http://dx.doi.org/10.5555/unique_doi_060103-02?urlappend=%3fpassed_param=some_value DOI 10.5555/unique_doi_060103-01 does have parameters on its registered URL , passed parameter are added as follows: http://dx.doi.org/10.5555/unique_doi_060103-01?urlappend=%26passed_param=some_value Since the 'urlappend' function is very primitive we must place the correct character (either a '?' or a '&') before the name-value pair information we wish to pass on to the target. In addition, with this approach the target's publisher may not be expecting incoming parameters and the values placed inside urlappend may conflict with names of parameters already on the registered URL. Procedure #2A more robust solution based on OpenURL is a bit more complicated but it has several advantages: 1. Operates without having to know that the DOI's registered URL already has parameters 2. Prevents parameter name collisions 3. Allows the recipient of the link (the host of the target) to control whether they get passed parameters or not 4. Establishes a common vocabulary for passed parameters reducing the need for bi-lateral coordination OpenURL 1.0 defines a set of parameters to be used when conveying information in a hyperlink. Parameter passing depends on two of these (rft_dat and rfr_dat) to act as 'wrappers' for the passed parameters and the existing parameters on the DOI's registered URL. Parameter rft_dat (referent data) will contain the entire registered URL's parameter set as a 'nested' string (sort of parameters within a parameter). Parameter rfr_dat (referrer data) holds another 'nested' parameter string containing the information the source wishes to pass on to the target. Data inside the rfr_dat should conform to the controlled vocabulary described in the Parameter Passing white paper.Since the DOI's registered URL parameters will be safely nested inside rft_dat, parameter passing will also forward to the target any non OpenURL parameters found on the source link. The intention here is to improve the flexibility of parameter passing; however, use of rfr_dat is strongly encouraged due to the controlled vocabulary. Example: The in-bound link http://dx.doi.org/openurl?url_ver=Z39.88-2003&rft_id=doi:10.5555/unique_doi_060103-01&rfr_dat=rfr_dat= cr_setver=01&cr_pub=Source Publisher&cr_work=Source Journal Title&cr_src=SRC-NAME is combined with the registered URL http://www.crossref.org/paramEcho?param=done¶m2=two to create the following outbound link http://www.crossref.org/paramEcho?url_ver=Z39.88-2003&rft_id=doi:10.5555/unique_doi_060103-01&rft_dat=param1= done¶m2=two&rfr_dat=rfr_dat=cr_setver=01&cr_pub=Source Publisher&cr_work=Source JournalTitle&cr_src=SRC-NAME (Note: For readability the examples are NOT shown in encoded form. If they were the rft_dat portion would look like this rft_dat=param1%3Ddone%26param2%3Dtwo) Working Example The following link uses a DOI without parameter passing and shows what the target system would receive for incoming information (click the link). The values of 'param1' and param2' are part of the URL registered in Handle for this DOI http://dx.doi.org/10.5555/unique_doi_060103-01 This next link uses the same DOI with parameter passing. Here the source of the link (this page) wants to send the name/value pair of 'stuff=good' to the target system. Following this link shows that the param1 and param2 variables are still passed to the target, but the are wrapped inside the rft_dat parameter. The data 'stuff=good' is also passed to the target inside the rfr_dat parameter. This demonstrates good practice in that name conflicts will be avoided. http://dx.doi.org/openurl?url_ver=Z39.88-2003&rft_id=doi:10.5555/ unique_doi_060103-01&rfr_data=stuff%3dgood This next link demonstrates how any top level parameter will also be passed to the target, but not wrapped in any OpenURL containers. Here the name value pair 'santa=claus' is appended to the link in a way that is not consistent with the OpenURL specification (however, the specification does not explicitly prohibit this). When you follow this link you'll see that the target receives this data http://dx.doi.org/openurl?url_ver=Z39.88-2003&rft_id=doi:10.5555/unique_doi_ 060103-01&rfr_data=stuff%3dgood&santa=claus This next link shows how the OpenURL based parameter passing handles potential conflicts in parameter names. Following this link you'll see that the variable 'param1' is passed to the target twice. However, the one nested inside rft_dat is safely know to be the one registered with the DOI's URL http://dx.doi.org/openurl?url_ver=Z39.88-2003&rft_id=doi:10.5555/unique_doi_060103-01¶m1=five Using the primitive urlappend function above the target can not tell which value of 'param1' came from the DOI or from the source link (note: in building this link I must know that the DOI has parameters on its registered URL and thus insert the '%26') http://dx.doi.org/10.5555/unique_doi_060103-01?urlappend=%26param1=five Using Stored Queries (aka. Query Match Alerts) Forward matching, or as its now known Query Match Alerts, is a feature whereby if a query fails when its first submitted, CrossRef will remember it and when a deposit is made that satisfies the query an email will be sent to the query's submitter. This eliminates the need to regularly poll CrossRef with failed queries to see if they match any recent deposit. In order to use this feature you must submit your queries as XML <?xml version = "1.0" encoding="UTF-8"?> <query_batch version="2.0" xmlns = "http://www.crossref.org/qschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <head> <email_address>YOU'R EMAIL ADDRESS</email_address> <doi_batch_id>SomeTrackingID2</doi_batch_id> </head> <body> <query key="query-key-1" enable-multiple-hits="false"> forward-match="true" <journal_title>Current Opinion in Oncology</journal_title> <author>Chauncey</author> <volume>13</volume> <first_page>21</first_page> <year>2001</year> </query> </body> </query_batch> The important points are to set the "forward-match" attribute to true, make sure you fill in you email address and to assign a unique ID to the query using the "key" attribute. When you submit a query that does not immediately match you will reeive a notice telling you the query has been stored for later evaluation. <?xml version="1.0" encoding="UTF-8" ?> <crossref_result version="2.0" xmlns="http://www.crossref.org/qrschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/qrschema/2.0 crossref_query_output2.0.xsd"> <query_result> <head> <email_address>ckoscher@crossref.org</email_address> <doi_batch_id>SomeTrackingID2</doi_batch_id> </head> <body> <query status="unresolved"> <journal_title>Test Publication</journal_title> <author>Smith</author> <volume>3</volume> <first_page>100</first_page> <year>1985</year> <msg>Query stored in CrossRef for forward matching</msg> </query> </body> </query_result> </crossref_result> After a deposit is made with this DOI you will receive an email with you query results. Please note the connection between the batch ID given for the XML query submission, the query key given for the individual query in the submission and the email results. Email subject: "Crossref stored query match: doi_batch_id=SomeTrackingID2 ; query_key=query-key-1" <?xml version = "1.0" encoding = "UTF-8"?> <crossref_result version="2.0" xmlns="http://www.crossref.org/qrschema/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crossref.org/qrschema/2.0 crossref_query_output2.0.xsd"> <query_result> <head> <email_address>ckoscher@crossref.org</email_address> <doi_batch_id>SomeTrackingID2</doi_batch_id> </head> <body> <query key="query-key-1" status="resolved"> <doi>10.5555/forward_match_test_2</doi> <issn>12345678</issn> <journal_title match="exact">Test Publication</journal_title> <author match="exact">Smith</author> <volume match="exact">3</volume> <issue>2</issue> <first_page match="exact">100</first_page> <year match="exact">1985</year> <publication_type>full_text</publication_type> </query> </body> </query_result> </crossref_result> Article Title/Author Search
|
|
|
||||||||||||||||
|
||||||||||||||
