xsd.crossref.4.4.1.relations.xsd Maven / Gradle / Ivy
Version: beta 0.3
This schema provides for creating relationships between items represented by crossref DOIs and other items that may
be defined by a DOI (crossref or other RA) or by some other identifier. New relation types will be added as they're needed.
Please contact [email protected] to request additions or changes.
Certain relationship types are covered elsewhere in the main deposit schema due primarily to specific processing or
the need to logically group those relations alongside other relevant metadata. For example cited-by relations are
created by the deposit of a citation_list. Crossmark->Updates addresses relationships between DOIs where a primary
item is updated, revised, hasErratum, withdrawn ... etc. When constructing relations please be sure to use the
the most appropriate metadata structure.
Relationships between DOIs in crossref are established bidirectionally between those DOIs making it unnecessary to
deposit relationship metadata for both DOIs.
Example:
DOI A metadata contains 'hasTranslation' with a target of DOI B will automatically
make this claim visible in metadata for B.
Seen from the perspective of B: A claims it hasTranslation of which B is the target of the claim.
Change history:
10/3/14 CSK removed reg-agency attribute. This is not necessary, can be derived from the DOI
10/3/14 CSK split into inter and intra relation elements
10/3/14 CSK pulled in common crossref schema for description element and language attributes
12/21/16 CSK added comments to each relation type indicating the appropriate inverse relation type
3/6/17 PDF added accession as identifier-type
====== C O N V E N T I O N ==============================================================================================
Relationships between two objects have an implicit directionality that in natural language terms dictate which object is the actor
and which is acted-upon. This directionality is semantically based on the relationship name. Crossref's model makes
no attempt to automatically 'understand' this semantic.
The identifier parent to the PROGRAM element is considered the claimant of the relationship (e.g. the entity that
establishes the relationship).
yes: 10.1234/abcd references 10.5678/efgh => 10.1234/abcd claims that it references 10.5678/efgh
yes: 10.1234/abcd referencedBy 10.5678/efgh => 10.1234/abcd claims that it is referenced by 10.5678/efgh
==========================================================================================================================
Accommodates deposit of relationship claims between items.
Description of the relationship to the target item or of the target item itself
Used to describe relations between items that are not the same work.
Used to define relations between items that are essentially the same work but may differ in
format, language, revision ... etc. Assigning different identifers to exactly the same item
available in one place or as copies in multiple places can be problematic and should be avoided.
An identifier systems may require a namespace that is needed in addition to the identifer value to provide uniqueness.