Language attributes are based on ISO 639
Mime types for component format. For mime types refer to http://www.iana.org/assignments/media-types/
The following are basic data types for face markup. Face markup that appears in the title, subtitle, and original_language_title elements should be retained when depositing metadata. Face markup in other elements (e.g. small caps in author names) must be dropped. Face markup support includes bold (b), italic (i), underline (u), over-line (ovl), superscript (sup), subscript (sub), small caps (scp), and typewriter text (tt).
See http://help.crossref.org/#face_markup
The following are basic data types for date parts.
Publisher generated ID that uniquely identifies the DOI submission batch. It will be used as a reference in error messages sent by the MDDB, and can be used for submission tracking.
The publisher must insure that this number is unique for every submission to CrossRef.
Indicates version of a batch file instance or DOI.
timestamp is used to uniquely identify batch files and DOI values when a DOI has been updated one or more times.
timestamp is an integer representation of date and time that serves as a version number for the record that is being deposited. Because CrossRef uses it as a version number, the format need not follow any public standard and therefore the publisher can determine the internal format. The schema format is a double of at least 64 bits, insuring that a fully qualified date/time stamp of 19 digits can be submitted.
When depositing data, CrossRef will check to see if a DOI has already been deposited for the specific doi value. If the newer data carries a time stamp value that is equal to or greater than the old data based on a strict numeric comparison, the new data will replace the old data. If the new data value is less than the old data value, the new data will not replace the old data.
timestamp is optional in doi_data and required in head. The value from the head instance timestamp will be used for all instances of doi_data that do not include a timestamp element.
Information about the organization submitting DOI metadata to CrossRef
Name of the organization registering the DOIs.
The name placed in this element should match the name under which a depositing organization has registered with CrossRef.
e-mail address to which batch success and/or error messages are sent.
It is recommended that this address be unique to a position within the organization submitting data (e.g. "doi@...") rather than unique to a person. In this way, the alias for delivery of this mail can be changed as responsibility for submission of DOI data within the organization changes from one person to another.
The organization that owns the information being registered.
The chapter, section, part, etc. number for a content item in a book.
Unlike volume and edition_number, component_number should include any additional text that helps identify the type of component. In the example above, the text "Section 8" appeared on the table of contents and it is reflected here. "8" is also acceptable, however the former treatment is preferred.
The type of the component is given the component_type attribute of content_item.
The edition number of a book.
edition_number should include only a number and not additional text such as "edition". For example, you should submit "3", not "third edition" or "3rd edition". Roman numerals are acceptable.
Publishers will update a print edition with a new edition number when more than ten percent of the content has changed. However, publishers expect to continuously update online editions of books without changing the edition number.
The ability to update the electronic version independent of the print version could be problematic for researchers. For example, if a research article cites the print version of a chapter, and a researcher subsequently links to the online version of the same chapter, the content may be different from the print version without the typical indication of a new edition. This topic requires further discussion outside of the scope of this specification.
The issue number in which an article is published.
Only one issue name should be used for the issue. The issue number takes precedence over any other name. For example, if an issue has only a seasonal name, then the season should be listed in issue. However, if an issue has a number and a season, then only the number should be listed in issue, and the season should be placed in month (see the table in month, below, for proper encoding of the season) if the specific month of publication is not known.
Do not include the words "issue", "No" or "number" in this element.
When submitting DOIs for journal articles published online ahead of print, you should submit the issue number, when known, even if the pagination information for the entity is not yet known.
Data may be alpha, numeric or a combination.
Examples:
74(3):1999
1999
74
3
Volume 74, Spring 1999
1999
74
Spring
Volume 74, issue 3 Spring 1999
21
1999
74
3
The container for elements related directly to a DOI.
doi_data contains the doi, timestamp (version) and corresponding resource (URI) data for the doi.
Cases of single-resolution (i.e. one DOI with a single corresponding URI) should be tagged with a doi/resource pair in doi_data.
If additional resources are to be proved the <collection> element may also be used. The single URL provided in the <resource> is mandatory and serves as the single resolution target for the DOI.
Note: A timestamp value placed inside doi_data will override any timestamp value placed in the <head> element.
The element that contains a URI associated with a DOI.
URLs are referred to as resources in the 2.0 CrossRef schema because they can be any valid URI.
Cases of single-resolution (i.e. one DOI with a single corresponding URI) should be tagged with a doi/resource pair in doi_data.
Only one resource is allowed per doi_data, the exception being resource elements within a collection element.
A collection is a container for one or more items each holding a doi or a resource (URI) which is related to the DOI in the ancestor <doi_data> element. A collection must be qualified by a property attibute or the multi-resolution attribute.
property attributes:
list-based: uses an interim page and presents the list of items to the user (via Multiple Resolution)
country-based: proxy picks destination based on the country code of the user's location (this option is not currently available)
crawler-based: identifies resource to be crawled by the specified crawlers.
The multi-resolution attribute may be used to lock or unlock DOIs for multiple resolution.
A container used to associate a collection, doi, or resource (URI) with zero or more property elements.
item is currently used for supplying as-crawled URLs (http://help.crossref.org/#as-crawled-urls)
property elements qualify the semantic meaning of a item or collection. property elements consist of a type/value pair where the property type is found in the type attribute and the value is found in the element content.
The property element is not currently in use.
The container for all who contributed to authoring or editing an entity.
The name of an organization (as opposed to a person) that contributed to authoring an entity.
If multiple organizations authored an entity, each one should be captured in a unique organization element. If an entity was authored by individuals in addition to one or more organizations, person_name and organization may be freely intermixed within contributors.
contributor_role should be set, as appropriate, to author or editor. When a contributor translated a work, set contributor_role to "translator". "chair" should only be used for conference proceedings to indicate a conference chair.
The name of a person (as opposed to an organization) that contributed to authoring an entity.
Authors with name suffixes should have the suffix captured in suffix, not in surname. Author prefixes such as "Dr.", "Prof.", or "President" should not be included in person_name or any other element. Author degrees (e.g. M.D., Ph.D.) also should not be included in CrossRef submissions.
contributor_role should be set, as appropriate, to author or editor. When a contributor translated a work, set contributor_role to "translator". "chair" should only be used for conference proceedings to indicate a conference chair.
A contributor's given name.
The given_name, combined with surname, forms the name of an author or editor. given_name may be submitted as either initials or a full name.
Do not place given_name within the surname unless it is unclear how to distinguish the given name from the surname, as may be the case in non-Western names.
Do not include titles such as "Dr.", "Prof.", or "President" in given_name. These titles should not be submitted to CrossRef.
The surname of an author or editor.
The surname, combined with given_name, forms the name of an author or editor. Whenever possible, the given name should not be included in the surname element.
In cases where the given name is not clear, as may happen with non-Western names or some societies in which surnames are not distinguished, you may place the entire name in surname, e.g.:
Leonardo da Vinci
If an author is an organization, you should use organization, not surname.
Suffixes should be tagged with suffix. Author degrees (e.g. M.D., Ph.D.) should not be included in CrossRef submissions.
The suffix of an author name, e.g. junior or senior.
A name suffix, that typically denotes a generation distinction, is tagged with suffix.
Author degrees (e.g. M.D., Ph.D.) should not be included in CrossRef submissions.
The institution(s) with which a contributor is affiliated. This element may hold the name and location of an affiliation with which a contributor is affiliated. Please note the following points when using this element:
1. A contributor may have up to five affiliations. Each affiliation should be in a unique <affiliation> element. The following is correct:
<affiliation>University of New Mexico</affiliation>
<affiliation>Sandia National Laboratories</affiliation>
The following is NOT correct
<affiliation>University of New Mexico; Sandia National Laboratories</affiliation>
2. The name of the institution is required in this element. The location is optional. Both of the following are correct:
<affiliation>Harvard University</affiliation>
<affiliation>Harvard University, Cambridge, MA</affiliation>
3. Additional address information such as a URL or email address should NOT be deposited in this element
4. Visual linking indicators used in publication to connect authors with their affiliations such as footnote symbols or initials should NOT be included in the <affiliation> element
5. If you have only a single string that has the affiliation for multiple contributors to a work and that string is not broken out into the individual affliations for each author, please do NOT deposit the affilation information. This element is to be used only for affiliation information that is directly connected to the author with whom this information is included within the person_name element.
A container for the title and original language title elements.
The title of the entity being registered.
When a title contains a subtitle, it is preferable to capture the subtitle portion in the subtitle element.
Use care to remove face markup (such as italic applied to genus or species names) from article titles as this markup is not supported by CrossRef.
The title of an entity in its original language if the registration is for a translation of a work.
When providing the original language of a title, you should set the language attribute.
The sub-title portion of an entity title.
When possible, it is better to tag a title and subtitle with separate elements. If this information is not available, it is acceptable to submit the title and subtitle all within the title element with punctuation (preferably a colon) used to separate the subtitle from the title.
When a subtitle is tagged, the space and punctuation between the title and subtitle text should not be included. The following examples illustrate correct and incorrect tagging practices:
Correct and optimal tagging:
The Human Brain
A Handbook
Correct but not optimal tagging:
The Human Brain: A Handbook
Incorrect:
The Human Brain:
A Handbook
The Human Brain
: A Handbook
Month of publication.
The month must be expressed in numeric format rather spelling out the name (e.g.. submit "10", not "October").
The month must be expressed with a leading zero if it is less than 10 (e.g. submit "05", not "5").
When a journal issue has both an issue number and a season, the issue number should be placed in issue. If the month of publication is not known, the season should be placed in month as a two-digit value as follows:
Season Value
Spring 21
Summer 22
Autumn 23
Winter 24
First Quarter 31
Second Quarter 32
Third Quarter 33
Fourth Quarter 34
In cases when an issue covers multiple months, e.g. "March-April", include only the digits for the first month of the range.
Day of publication.
The should must be expressed with a leading zero if it is less than 10 (e.g. submit "05", not "5").
Year of publication.
The date of publication.
In all cases, multiple dates are allowed to allow for different dates of publication for online and print versions.
This element was previously called date, but was renamed publication_date to distinguish more clearly from conference_date.
The container for information about page ranges.
When an entity has non-contiguous page information, you should capture the first page range in first_page and last_page. Any additional page information should be captured in other_pages.
Punctuation is only allowed in other_pages. It should not appear in first_page and last_page.
Page number letter prefixes or suffixes should be included. Roman numeral pages are permitted in both upper case and lower case.
Data may be alpha, numeric or a combination.
First page number where an entity is located.
Data may be alpha, numeric or a combination.
The last page number of an entity.
last_page should not be used when the last page number is the same as the first page number (i.e. when the entire entity fits on one page).
Do not include punctuation for a page range in last_page.
If the entity has non-contiguous paging, use last_page for the last page of the first range and place all other page information into other_pages.
Data may be alpha, numeric or a combination.
Used to capture additional page information when items do not encompass contiguous page ranges.
When an entity has non-contiguous page information, you should capture the first page range in first_page and last_page. Any additional page information should be captured in other_pages.
You should include commas or hyphens to express discrete pages or page ranges. endash entities should be converted to ASCII hyphens. Spaces should not be included. Note that punctuation should never appear in first_page and last_page.
Data may be alpha, numeric or a combination.
DOI for an entity being registered with CrossRef. In 2008 CrossRef restricted DOI suffix
characters to the following: "a-z", "A-Z", "0-9" and "-._;()/"
Existing DOIs with suffix characters outside of the allowed set are still supported. For additional
information on DOI syntax, see http://help.crossref.org/#ID5755
The ISBN assigned to an entity.
If a multi-volume work has one ISBN per volume and a unique ISBN for the series, all may be registered. The ISBN for the series must be in series_metadata, and the ISBN for each volume in proceedings_metadata, or book_metadata, respectively.
The text "ISBN" should not be included in the ISBN element in CrossRef submissions.
Although not required, the ISBN number should retain spaces or hyphens that appear in the formatted number because they aid in human-readability. For more information, please see http://www.isbn.org/standards/home/isbn/international/hyphenation- instructions.asp or http://www.isbn.org.
Identifies books or conference proceedings that have no ISBN assigned.
In very limited cases a book may never have an ISBN, this is particularly true for older texts.
Conference proceedings, however, may regularly have a volume number but no ISBN or volume title.
The ISSN assigned to an entity.
The ISSN must consist of eight digits (where the last digit may be an X), or it must consist of eight digits in two groups of four with a hyphen between the two groups. Spaces or other delimiters should not be included in an ISSN. For more information, please see http://www.issn.org:8080/English/pub/getting- checking/checking or http://www.issn.org.
The text "ISSN" should not be included in the issn element in CrossRef submissions.
CrossRef validates all ISSNs supplied in deposits, only valid ISSNs will be accepted.
The coden assigned to a journal or conference proceedings.
The volume number of a published journal, or the number of a printed volume for a book or conference proceedings.
A journal volume is contained in the journal_volume element to allow for the assignment of a DOI to an entire journal volume.
Do not include the words "Volume" or "vol." in this element.
Data may be alpha, numeric or a combination. Roman numerals are acceptable.
A list of articles, books, and other items cited by the parent item for which the DOI in the doi_data is being deposited.
Some articles may have multiple lists of citations (e.g. main reference list, appendix reference list, etc.). All citations for one article should be included in a single citation_list regardless of whether one or more citation lists were in the original item.
When combining multiple reference lists from an item into one citation_list element, but sure to give each citation a unique key attribute value. For example, if an appendix in an item has a separate citation list that restarts numbering at 1, these citations should be given key attributes such as "ab1" rather than "b1".
Some articles may contain "Further Reading" or "Bibliography" lists. The distinguishing factor in these lists is that the references have not been cited from the article—they only provide a list of additional related reading material. It will be left to the discretion of the publisher if these items are to be considered citations and should be deposited.
NOTE: If a citation_list element is given and is empty then all citations for the given DOI will be deleted, otherwise any existing citations for the given DOI are left intact in the database. It is quite common that a publisher wants to fix the DOI's metadata without resubmitting the citations. Leaving out the citation_list element will do that.
Also note that any given citations will override older citations for the given DOI so citation_lists are not cumulative over multiple records or submissions.
citation is used to deposit each citation in the reference list of the item for which the DOI is being deposited. The citations in the list will be run by the CrossRef system as queries looking for the DOI of the articles being cited.
NOTE: Because the citation list is used to support forward linking, the more information supplied in the citation the better the chance of finding a match.
For each citation that is deposited, one of four models should be used:
1. Parsed journal data
2. Parsed book or conference data
3. DOI
4. Unstructured citation (not yet supported for resolution)
When parsed journal, book or conference data is deposited, CrossRef will perform a lookup to find the DOI.
Each citation must be given a unique ID in the key attribute. It is recommended that this number be the citation number if the reference list is numbered in the published article, or the underlying XML ID if the reference list is name/date style in article.
When submitting a journal citation, it should include an issn, journal_title or both. journal_title only is preferred over issn only. In addition the first author and first_page number should be submitted. The first_page number is preferred, but for those citations that are "in press", the author should be submitted. All elements are optional, however for best linking results, as much information as is known should be submitted.
When submitting a book or conference citation, it should include an isbn, series_title, volume_title, or any combination of these three elements as may be available. All elements are optional, however for best linking results, as much information as is known should be submitted.
When a DOI is already known for a citation, you may submit just the doi without additional information.
When parsed information is not available for a citation, or the citation is of a type other than journal, book, or conference proceeding that is supported by CrossRef (e.g. standard, patent, thesis, newspaper, personal communication, etc.), it may be submitted using the unstructured_citation element. CrossRef is able to process some unstructured citations. When submitting unstructured citations, it is helpful, but not required to include all available face markup (e.g. bold, italic, etc) as this will make possible future parsing of the unstructured citation more accurate. In such cases, it is preferred, but not required, if the citation number (when Vancouver style is used) be removed from the unparsed citation. This number can be submitted using the key attribute
Only the first author of a citation should be submitted, not the entire author list.
Only the surname is required. Initials may be included, but are not recommended because the best linking results can be provided if initials are omitted. Author titles, roles and generation information should not be included. If the first author is an organization, the organization name should be submitted in the author element.
cYear has a loose text model that can accommodate non-standard years such as year ranges such as "1998-1999". Note that years such as "1998a" or "1999b" should be deposited without the letter, e.g. "1998" or "1999", whenever possible.
Citations that are "in press" should be submitted with as much information as is available.
citation_key allows the publisher to assign a unique ID to each citation that is deposited. It is recommended that this attribute be given the reference number if the publication uses reference numbers.
For those publications that use name/date style citations, it is recommended that this attribute be used to indicate the sequential number of the citation in the reference list. However, some schema must be utilized as this is a required attribute. The system will use this key value to track the specific reference query and will return this value along with the DOI.
A citation that is to an item other than a journal article, book, or conference paper and cannot be structured with the CrossRef citation model. Also, it is used for a citation to a journal article, book, or conference paper for which the depositing publisher does not have structured information.
unstructured_citation allows a publisher to deposit references for which no structural information is available. These may be journal, book, or conference references for which the supplier did not provide markup, or other types of references (e.g. standards, patents, etc) which are not supported by CrossRef.
This structure permits publishers to deposit complete reference lists, without regard to the availability of markup, or the need to parse references beyond those types that CrossRef supports.
CrossRef's ability to process unstructured citations is limited, for details see http://help.crossref.org/#ID38855
Journal title in a citation. Only used in the citation element.
Journal title in citation deposits is used for both abbreviated and spelled out journal names. No attribute is required to distinguish between name types. Both Proc. Natl. Acad. Sci. U.S.A. and Proceedings of the National Academy of Sciences of the United States of America are valid journal titles to use in this element.
Book series title in a citation. Only used in the citation element.
series_title is an element for the deposit of book or conference series titles in citations without the hierarchy required by the series_metadata element. Note that face markup is not permitted when this element is deposited as part of a citation.
Book volume title in a citation. Only used in the citation element.
volume_title is an element for the deposit of book or conference volume titles in citations without the hierarchy required by the titles element. Note that face markup is not permitted when this element is deposited as part of a citation.
First author in a citation. Only used in the citation element.
The author element tags one author name in a citation without the hierarchy required by the contributors or person_name elements
Only the first author should be deposited for each item. The author surname is required. Author initials may be added but are not recommended because queries work best when only the last name is provided. For example, the author "John Doe" can be deposited as Doe or
Doe J, but the former style is recommended.
If the author of a work is an organization rather than a person, the organization may be deposited as in: World Health Organization
Year of publication in citation.
Unlike the year element, cYear has a loose text model that can accommodate non-standard years such as year ranges such as "1998-1999".
Note that years such as "1998a" or "1999b" should be deposited without the letter, e.g. "1998" or "1999". The letter is used for internal source document linking in name/date (Harvard) style documents rather than external cross reference linking to the original item.
Article title in a citation.
Use care to remove face markup (such as italic applied to genus or species names) from article titles as this markup is not supported by CrossRef.
The element for depositing a stand alone component. The parent DOI must already exist (created in an earlier deposit or via some other registration process).
The wrapper element for including a group of components under a journal article, conference proceeding, book chapter, stand alone component, dissertation, technical report or working paper, standard, or database.
A container element that allows registration of supplemental information for a journal article, book chapter, or conference paper such as figures, tables, videos, or data sets.
Currently, the deposit of components primarily achieves only the first objective as the CrossRef system is not setup yet to support queries for components. The metadata associated with a component is intended to enable simple lookup searches of components in the future.
When deposited as part of the metadata for a higher level work the parent DOI is implicitly known via the XML hierarchy. When deposited separately the DOI of the higher level work must be provided explicitly (see sa_component)
All descriptive elements are optional allowing for the creation of simple anonymous DOIs. The 'parent_relation' attribute is mandatory and refers to the DOI described in the component's direct parent.
Normally book content that is published as a series is required to have a series title with an ISSN and a book title and/or a book volume number along with a book ISBN. An exception is when book chapters are published on line first prior to being assigned to a specific book in which case only the series title (and ISSN) is known at time of DOI registration.
Element unassigned_content is used as a placeholder to force recognition of this condition and thus prevent accidental omission of book level title information.
When unassigned_content is present the system will allow omission of the ISBN. If unassigned_content is not present the system will require an ISBN for the book title.
A narrative description of a component (e.g. a figure caption or video description) which may be independent of any host document context. The description element may be present more than once to provide alternative language values.
A narrative description of a component's file format and/or the file extension (for mime types refer to http://www.iana.org/assignments/media-types/)
The format element may contain only the mime_type attribute, or in addition it may contain a narrative description of the file format. Be sure to use the narrative portion to description only the format of the component and not the actual content of the component (use description to describe the component's content).
Container element for CrossMark data.
Required element. Some publishers encourage broad third party hosting of the publisher's content. Other publishers do not. And still others vary their policy depending on whether a particular article has been published under an OA policy or not. This boolean flag allows the publisher to indicate whether the CrossMarked content will only legitimately be updated on the CrossMark domain (true) or whether the publisher encourages updating the content on other sites as well (false).
A DOI which points to a publisher's CrossMark policy document. Publishers might have different policies for different publications.
Container element for crossmark_domain.
A list of domains where the publisher maintains updates and corrections to their content. Minimally, one of these should include the Internet domain name of the publisher's web site(s), but the publisher might also decide to include 3rd party aggregators (e.g. Ebsco, IngentaConnect) or archives with which the publisher has agreements to update the content
This should be a simple Internet domain name or subdomain name (e.g. www.psychoceramics.org or psychoceramics.org). It is used to identify when a referring URL is coming from a CrossMark domain.
A "crossmark_domain" is made up of two subelements; a "domain" and a "filter". The domain is required but the filter is optional and is only needed for use in situations where content from multiple publishers/publications is on the same host with the same domain name (e.g. an aggregator) and one needs to use the referrer's URI "path" to further determine whether the content in a crossmark domain.
Required element. This should be a simple Internet domain name or subdomain name (e.g. www.psychoceramics.org or psychoceramics.org). It is used to identify when a referring URL is coming from a CrossMark domain.
Optional element. The filter element is used to disambiguate content in situations where multiple publishers share the same host (e.g. when on an aggregated platform). It should contain a substring of the path that can be used to uniquely identify a publisher's or publication's content. For instance, using the string "alpsp" here would help the CrossMark system distinguish between ALPSP publications on the ingentaconnect host and other publications on the same host.
Optional element. A document might provide updates (e.g. corrections, clarifications, retractions) to several other documents. When this is the case, the DOIs of the documents that are being *updated* should be listed here.
The DOI of the content being updated (e.g. corrected, retracted, etc.)
In the CrossMark Terms and Conditions "updates" are defined as changes that are likely to "change the reader’s interpretation or crediting of the work." That is, *editorially significant* changes. "Updates" should not include minor changes to spelling, punctuation, formatting, etc.
Attributes:
label: Required attribute. This should be a human-readable version of the "type" attribute. This is what gets displayed in the CrossMark dialog when there is an update.
type: Required attribute. This attribute should be used to give the machine-readable name of the update type. The human-readable version of the type should be but in the "label" attribute.
There are many "types" of updates. "Corrections, "clarifications", "retractions" and "withdrawals" are just a few of the better-known types. For these common types we recommend you use the values "correction", "clarification", "retraction" and "withdrawal" respectively as per your editorial policy.
However, different publishers sometimes have to support different, custom update types- for instance, "protocol amendments", "letters of concern", "comments", etc. The attribute supports custom types as well.
date: The date of the update will be displayed in the CrossMark dialog and can help the researcher easily tell whther they are likley to have seen the update.
Required attribute. This should be a human-readable version of the "type" attribute. This is what gets displayed in the CrossMark dialog when there is an update.
Required attribute. This attribute should be used to give the machine-readable name of the update type. The human-readable version of the type should be but in the "label" attribute.
There are many "types" of updates. "Corrections, "clarifications", "retractions" and "withdrawals" are just a few of the better-known types. For these common types we recommend you use the values "correction", "clarification", "retraction" and "withdrawal" respectively as per your editorial policy.
However, different publishers sometimes have to support different, custom update types- for instance, "protocol amendments", "letters of concern", "comments", etc. The attribute supports custom types as well.
Required attribute. The date of the update will be displayed in the CrossMark dialog and can help the researcher easily tell whther they are likley to have seen the update.
Optional element. Publishers are encouraged to provided any non-bibliographical metadata that they feel might help the researcher evaluate and make better use of the content that the Crossmark record refers to. For example, publishers might want to provide funding information, clinical trial numbers, information about the peer-review process or a summary of the publication history of the document.
An assertion is a piece of custom, non-bibliographic metadata that the publisher is asserting about the content to which the CrossMark refers.
assertion attributes:
explanation: If the publisher wants to provide a further explanation of what the particular "assertion" means, they can link to such an explanation by providing an appropriate url on the "explanation" attribute.
group_label: This is the human-readable form of the "group_name" attribute. This is what will be displayed in the group headings on the CrossMark metadata record dialog.
group_name: Some assertions could be logically "grouped" together in the CrossMark dialog. For instance, if the publisher is recording several pieces of metadata related to funding sources (source name, percentage, grant number), they may want to make sure that these three assertions are grouped next to each-other in the CrossMark dialog. The group_name attribute is the machine-readable value that will be used for grouping such assertions.
label: This is the human-readable version of the name attribute which will be displayed in the CrossMark dialog. If this attribute is missing, then the value of the assertion will *not* be displayed in the dialog. Publishers may want to "hide" assertions this way in cases where the assertion value is too large or too complex to display in the dialog, but where the assertion is nonetheless valuable enough to include in API queries and metadata dumps (e.g. detailed licensing terms).
name: This is the machine-readable name of the assertion. Use the "label" attribute to provide a human-readable version of the name.
order: The publisher may want to control the order in which assertions are displayed to the user in the CrossMark dialog. All assertions will be sorted by this element if it is present.
Optional attribute. If the publisher wants to provide a further explanation of what the particular "assertion" means, they can link to such an explanation by providing an appropriate url on the "explanation" attribute.
Optional attribute. This is the human-readable form of the "group_name" attribute. This is what will be displayed in the group headings on the CrossMark metadata record dialog.
Optional attribute. Some assertions could be logically "grouped" together in the CrossMark dialog. For instance, if the publisher is recording several pieces of metadata related to funding sources (source name, percentage, grant number), they may want to make sure that these three assertions are grouped next to each-other in the CrossMark dialog. The group_name attribute is the machine-readable value that will be used for grouping such assertions.
Optional attribute. This is the human-readable version of the name attribute which will be displayed in the CrossMark dialog. If this attribute is missing, then the value of the assertion will *not* be displayed in the dialog. Publishers may want to "hide" assertions this way in cases where the assertion value is too large or too complex to display in the dialog, but where the assertion is nonetheless valuable enough to include in API queries and metadata dumps (e.g. detailed licensing terms)
Required attribute. This is the machine-readable name of the assertion. Use the "label" attribute to provide a human-readable version of the name.
Optional attribute. The publisher may want to control the order in which assertions are displayed to the user in the CrossMark dialog. All assertions will be sorted by this element if it is present.
Optional attribute