With the introduction of the new 5.5 schema, blogs can now be correctly identified in posted content instead of using ‘other’ as the sub-type. In this post, I’ve focused on changing the type attribute in the XML, as shown in the markup guide, updated it to 5.5.0, and demonstrated how I use our XML schema documentation to see what options are available.
For posted content, XML submissions are required to deposit new metadata and update existing records using one of the XML deposit methods. It is not possible to do this in the new Metadata Manager, or our older helper tool, the Web Deposit Form.
If you previously deposited posted content, you may have used an older schema. In the following example, I updated a record (DOI 10.5555/other_to_blog) I previously deposited using schema version 5.3.1. To see what attributes were available when I deposited, I used the documentation for this version, which can be found in our schema library. These can seem overwhelming if this is your first time using it, but it is a marvelous resource for finding out what choices, requirements, or order the elements are expected for a particular schema. Do feel free to respond below if you would like a post on how to interpret the schema documentation.
Below, I’ve provided a screenshot of the posted_content element, (found by using the search feature in my browser), which shows the different types available at the time for this version: preprint, working_paper, letter, dissertation, report, review, and other.
Previously, I had deposited my blog post as sub-type “other” as this seemed the most fitting value at the time. Below, the XML view for this record showed the type within the <posted_content> element.
To update from the older version to the recent schema 5.5.0, I found the link to the documentation in our schema library. Once I’ve opened the documentation, I looked for ‘posted_content’ on the left, and then selected ‘type’ in ‘Attributes’ for a detailed view. Bold lines connecting elements or attributes indicate required items. Selecting any element or attribute will provide a detailed view of its definition.
In the screenshot below, the sub-type values available in schema version 5.5.0 are: preprint, blog, letter, other, poster, and review. As the new sub-type more accurately described the published content (a blog), I can modify my previous XML file to update the record for this DOI.
Using an XML Editor, I changed the schema declaration from 5.3.1 to 5.5.0. If you don’t feel comfortable changing the declaration on your own, you can always cut and paste one from the best practice examples on our GitLab. In this case, I used everything in the <doi_batch> tag.
<doi_batch xmlns:xsi="``http://www.w3.org/2001/XMLSchema-instance``" xsi:schemaLocation="``http://www.crossref.org/schema/5.5.0`` ``https://www.crossref.org/schemas/crossref5.5.0.xsd``" xmlns="``http://www.crossref.org/schema/5.5.0``" xmlns:jats="``http://www.ncbi.nlm.nih.gov/JATS1``" xmlns:fr="``http://www.crossref.org/fundref.xsd``" version="5.5.0">
Then, I updated the type=”blog” in the attribute of <posted_content> as shown below in a screenshot of my XML editor. I also updated the timestamp to avoid a timestamp error when resubmitting this file.
If you’re feeling less than confident with your XML prowess, as I do sometimes, you can always use our XML Parser to check for any errors, particularly if your XML editor does not have validation. [Note that our XML Parser hasn’t been updated with the new element in <person_name>, so you may safely ignore those errors related to if you are using schema 5.5.0.]
Once I deposited the updated XML file using my usual method, (I used our admin tool), and allowed time for our system to index the new record, the XML view indicated the type had changed to ‘blog’.
If you are working in our admin tool, you can look up the submission and see that the submission log, (the same one that is received in the email included in the XML), showed the DOI record was successfully updated.
This type of record change does not create any warnings in your submission log - all you should see is that your record was updated successfully. Had there been a problem, the submission log is the first place we look for clues. Of course, if you run into any trouble, you are welcome to reach out to us at support@crossref.org.
Note: I’ve constructed the DOI for this example using a poorly constructed suffix! Please follow best practices for constructing your suffixes as shown in our documentation.
Thanks for reading!
Poppy