datacite / schema Goto Github PK

View Code? Open in Web Editor NEW

42.0 18.0 16.0 26.19 MB

DataCite Metadata Schema Repository

Home Page: https://schema.datacite.org

HTML 8.92% Ruby 76.51% JavaScript 0.01% TeX 0.20% Dockerfile 0.33% XSLT 11.08% SCSS 2.95%

schema's Introduction

DataCite Schema Repository

This repository holds the official metadata schemas from DataCite as required by the DataCite Metadata Store.

It contains the schemas itself along with examples and documentation.

Schemas

Each schema has its own folder under /source/meta e.g. /source/meta/kernel-2.0/. This directory is allowed to contain only one xsd. The directory structure is as follow:

/source/meta/{schema-name}/{filename}.xsd   root xsd
/source/meta/{schema-name}/include/         referenced xsd files
/source/meta/{schema-name}/example/         example xml files
/source/meta/{schema-name}/doc/             documentation

The /source/meta directory will be published at http://schema.datacite.org, e.g.

http://schema.datacite.org/meta/kernel-2.0/metadata.xsd

Feedback

If you have any questions about the metadata schema, please contact [email protected].

If you have an idea for a change to the DataCite Metadata Schema, let us know through this form: DataCite Metadata Schema Suggestions.

We recommend first reviewing the ideas on the DataCite Metadata Schema Trello board to see if a similar idea has already been proposed. If it has, you can contribute to the discussion by following the instructions on the card.

Learn more about contributing to the DataCite Metadata Schema here: DataCite Schema - Contribute.

Tests

There are tests to check the directory structure, existence of examples, validity of the schemas, and validity of the examples.

You can execute the tests via

rspec

schema's People

Contributors

Stargazers

Watchers

Forkers

pietsch nichtich b-rich lnielsen mikejmets espacial cgars tobiadolph olegkorniichuk caltechlibrary florianfranz ninalewin bernwaldl yarikoptic front-matter

schema's Issues

DataCite Metadata Schema 4.1 documentation nameType attribute bug

https://schema.datacite.org/meta/kernel-4.1/doc/DataCite-MetadataKernel_v4.1.pdf

has typos in the nameType attribute values.

https://schema.datacite.org/meta/kernel-4.1/include/datacite-nameType-v4.1.xsd lists "Personal" and "Organizational" (with z) as enumeration values.

The PDF lists "Organisational" (with s) on p. 14, table row 2.1.1, and p. 22, table row 7.7 . Please correct to "Organizational".

Provide DataCite JSON for schema 4.2 examples

Need a distribution concept

Since sizes and formats (and perhaps language, versions, descriptions...) are specific to different distributions, it would make a much better metadata scheme if there were a distributions metadata element. I.e. align with DCAT...

add dead link check test

integrate testing of non-valid example

Currently we check if provided examples for a schema are valid. It might be useful to also test some examples which are not valid. This will make the tests more accurate.

ORCID representation in DataCite XML

Hi All,

I wanted to ask your opinion on 2 issues related to the way ORCIDs are represented in DataCite XML files.

The examples provided on the Datacite website (e.g. https://schema.datacite.org/meta/kernel-4.1/example/datacite-example-full-v4.1.xml ) seem to indicate that the ORCID value needs to be represented in the dddd-dddd-dddd-dddd format.

However, the new ORCID guidance (https://support.orcid.org/knowledgebase/articles/116780) says that:

When stored, the ORCID iD should be expressed as a full https URI: https://orcid.org/xxxx-xxxx-xxxx-xxxx, complete with the protocol (https://), and with hyphens in the identifier (xxxx-xxxx-xxxx-xxxx).

Is the value of the ORCID field in the Datacite XML going to continue being expressed in the current format, or do you reckon that the new format suggested by ORCID will be adopted?

The current schemeURI is "http://orcid.org/" - will it be changed to 'https://orcid.org/'? Can the https URI be used?

Thank you,
Michele

allow optional wrapper elements to be empty

it should be allowed to leave optional wrapper elements like <contributors/> empty.

The benefit: It makes converting to our schema e.g. via xslt more straight forward, because you don't need to handle different cases. And having empty elements it totally harmless.

add more tests

has index.html
has documentation
html pages valid
test for oai schema
link checker

Schema 4.2 change with nonemptycontentStringType

Be more flexible with nonemptycontentStringType in schema 4.2

Affiliations should have optional identifiers

Affiliations are plain dump strings. It should be allowed to add identifiers e.g. GRID, ORCID, VIAF, GND... for the organization.

Deprecated metadata scheme is 1st hit in Google

The first hit in Google for "DataCite metadata" is an old version of the schema:
http://www.datacite.org/schema/DataCite-MetadataKernel_v2.0.pdf

Ideally the first hit would be:
http://schema.datacite.org

Is there anything we can do about this? Can the old scheme be removed as it is no longer supported? If not, maybe we could add a nofollow in the robots.txt?

Cheers,
Tom

provide changelog for schema versions

homepage should link to oai schema

Update Citation in Documentation

The citation-example should be done with the URL version of the DOI to be consistent with the DataCite homepage and the reccomendation of CrossRef.

use another schemalocation for xml namespace

http://www.w3.org/2001/xml.xsd is not static but may change in the future. Also currently it takes about 30 seconds to retrieve the xsd, which causes jenkins to take way too long for executing the tests. This might also causes problems with MDS.

We should use http://www.w3.org/2009/01/xml.xsd. You can find more information there.

Validation of identifier

Hi,

I'm submitting this issue in my role as co-chair of the RDA Research Data Repository Interoperability WG. We plan to use datacite to provide minimal, standardized metadata for our recommendation for an interoperable, BagIt-based exchange format for digital content between repository platforms.

One possible concern about using datacite, the necessity of a DOI, came up during one of our virtual meetings. As we are not focussing solely on published datasets the presence of a DOI cannot be guaranteed, probably for the majority of packages created according to our recommendations. Luckily, the datacite schema documentation states that if [...]one of the
required properties is unavailable[...] one should [...]use one of the standard (machine‐recognizable) codes listed in Appendix 3[...] (see Section 2.3).

However, according to the XSD schema this seems not to apply to the identifier. That's why I wanted to ask if this is a bug/feature in the schema implemenation or a misinterpretation/inaccuracy of the schema documentation?

Thanks in advance for the clarification.

Regards,
Thomas

allow arbitrary ordering of elements

get rid of <xs:sequence>

Nokogiri version out of date

Potential security vulnerability we need update the gem file for nokogiri to something greater than 1.8.1
gem 'nokogiri', '~> 1.8.1

Need to check libraries that depend on this, might need to upgrade them too.

add custom 404 error page

Add ID to controlled list entries

Mail from Alex Ball, on 2012-02-16:

DataCite Dublin Core Application Profile (DC2AP) ready for release, and a
couple of them involve the controlled vocabularies used for some DataCite
schema properties. The vocabularies in question are contributorType and
resourceType.

I was experimenting with reproducing them in RDF, but a far more sustainable
solution would be to reuse the XSDs you are already producing. According to
this document:
http://www.w3.org/TR/swbp-xsch-datatypes/
it would be very easy to do this if you were to add ID attributes to the
simpleType elements in your included XSDs, e.g.

xs:simpleType id="contributorType" name="contributorType"

and

xs:simpleType id="resourceType" name="resourceType"

Delete "mixed=true" from resourceType

Think before you delete, but it seems, this is not necessary.

examples are not checked recursively

Add "PublicationPlace" to "descriptionType"

Chage wording in documentation

Paragraph 1.2: Change "The first is the release of a second version of the schema, this one being in a Dublin Core application profile format" to: "The first is the release of a second version of the schema, in a Dublin Core application profile format"

Adressing version issues in the documentation

a. Change wording of “Allowed values, examples and other constraints” column for Version to accommodate major.minor tracking; consider using some language from http://wiki.esipfed.org/index.php/Interagency_Data_Stewardship/Citations/provider_guidelines#Note_on_Versioning_and_Locators

b. Add text to introduction regarding dynamic datasets

c. Make sure that one of the example citations includes a version (and this needs to be in sync with website)

oai datacite wrapper schema needs to be put in the repository

Enumerations should reflect the correct casing used in xsd.

When validating DataCite XML against our schema XSD, sometimes errors are generated that are confusing because they do not take into account case sensitivity.

e.g.

"[facet 'enumeration'] the value 'personal' is not an element of the set {'organizational', 'personal'}. at line 6, column 0"

Which of course looks werird, the problem here is the enumeration for nameType here is actually "Organisation" and "Personal"

Use of xsd:all vs. xsd:sequence

Current XSD for v3.1 makes use of xsd:sequence instead of xsd:all for e.g. creator properties. This means that the elements (creatorName, nameIdentifier and affiliation) must come in the exact order specified by the schema.

This means that the following is valid according to the schema:

<creator>
  <creatorName>Smith, John</creatorName>
  <nameIdentifier schemeURI="http://orcid.org" nameIdentifierScheme="ORCID">0000-1234-5678-0000</nameIdentifier>
  <affiliation>John College</affiliation>
</creator>

but that this is not (changed order of affiliation/nameIdentifier):

<creator>
  <creatorName>Smith, John</creatorName>
  <affiliation>John College</affiliation>
  <nameIdentifier schemeURI="http://orcid.org" nameIdentifierScheme="ORCID">0000-1234-5678-0000</nameIdentifier>
</creator>

Here's a full Python example that demonstrates the problem:

# Require lxml so make sure to first install lxml using "pip install lxml"
from lxml import etree

xsd = etree.XMLSchema(file='http://schema.datacite.org/meta/kernel-3/metadata.xsd')

doc1 = """
<resource xmlns="http://datacite.org/schema/kernel-3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://datacite.org/schema/kernel-3 http://schema.datacite.org/meta/kernel-3/metadata.xsd">
  <identifier identifierType="DOI">10.1234/foo</identifier>
  <creators>
    <creator>
      <creatorName>Smith, John</creatorName>
      <affiliation>John College</affiliation>
      <nameIdentifier schemeURI="http://orcid.org" nameIdentifierScheme="ORCID">0000-1234-5678-0000</nameIdentifier>
    </creator>
  </creators>
  <titles>
    <title>Dataset name</title>
  </titles>
  <publisher>Somewhere</publisher>
  <publicationYear>2016</publicationYear>
</resource>
"""

doc2 = """
<resource xmlns="http://datacite.org/schema/kernel-3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://datacite.org/schema/kernel-3 http://schema.datacite.org/meta/kernel-3/metadata.xsd">
  <identifier identifierType="DOI">10.1234/foo</identifier>
  <creators>
    <creator>
      <creatorName>Smith, John</creatorName>
      <nameIdentifier schemeURI="http://orcid.org" nameIdentifierScheme="ORCID">0000-1234-5678-0000</nameIdentifier>
      <affiliation>John College</affiliation>
    </creator>
  </creators>
  <titles>
    <title>Dataset name</title>
  </titles>
  <publisher>Somewhere</publisher>
  <publicationYear>2016</publicationYear>
</resource>
"""

# Invalid doc
xsd.assertValid(etree.XML(doc1))
# Valid doc
xsd.assertValid(etree.XML(doc2))

affiliation xml:lang attribute

Not entirely sure this is the right place to bring this up, but it is related to the DataCite schema. When trying to update records (using DataCite schema 4.1), we are now encountering errors regarding the contributor and creator affiliations. We would previously have two values with an xml:lang attribute on each, for example:
<affiliation xml:lang="en">National Research Council Canada</affiliation>
<affiliation xml:lang="fr">Conseil national de recherches Canada</affiliation>

This no longer validates with the recent updates. Is this intended? Should the update be made just to strip the xml:lang attribute (see below), or is there another/better way to convey this?
<affiliation>National Research Council Canada</affiliation>
<affiliation>Conseil national de recherches Canada</affiliation>

Thank you,
Marc Dion

Some errors in 4.1 changelog and docs

In the 4.1 changelog (both on the website and the PDF) it's stated that Addition of new “dateInformation” subproperty for dateType - it should be a subproperty of "Date".
The website says: Addition of a new optional “nameType” attribute for Creator and Contributor. Controlled list: personal, organizational, while in the PDF docs:
Addition of a new optional attribute for creatorName and ContributorName: nameType. It's not clear whether it's a subproperty of the top-level fields (Creator/Contributor) or the corresponding creator/contributorName subproperties. From the table it's also not clear: Under 7 Contributor, the nameType looks like a direct sub-property: 7.7 nameType, however under 2 Creator it looks like a sub-property of 2.1 creatorName: 2.1.1 nameType. ~~I guess it should be either of those and kept consistent between the Contributor/Creator fields?~~ From the schema it looks like nameType is a subproperty of the creator/contributorName.
~~Addition of optional lang attribute to Rights property - "lang" is missing from the table.~~ Misunderstood this point.

Documentation has problem with foot notes

Not sure if this is place to report it, but the current 3.0 PDF (Jan 2014) has a problem with the foot notes.

Page 18: Footnote 20 refered to from 18.1 geoLocationPoint is missing (supposedly it's the same as 23). Also footnote 19 is missing (referred to from the text), as well as foot notes 21, 22 (couldn't find them in the text).

Add new option to relationType: IsIdenticalTo

IsIdenticalTo (indicates that A is identical to B, for use when there is a need to register two separate instances of the same object)

Fix broken links in schema website

Fix language examples

<language>eng</language>

should be

<language>en</language>

better pattern in doiType

The currently used pattern [1][0][/.].* matches 10/foo. Probably [1][0][.].* or 10\..* was meant?!

I propose a slightly more accurate one: 10\..+/.+. This also checks for general prefix/suffix structure.

Add "schemeURI" attribute to CreatorName, ContributorName and Subject

Inconsistent order of subproperties 7.3 familyName and 7.4 givenName

There is an inconsistency in the order of subproperties between Creator and Contributor: creator has 2.2 givenName and 2.3 familiyName (e.g. givenName comes before familyName), whereas contributor has 7.3 familyName and 7.4 givenName. This is relevant because XML schema definition is sensitive to the order of elements, e.g. for a XML serialization, the subproperties must appear in the proper order in the XML file, otherwise validation will fail. In fact, the XSD file lists givenName before familyName in the subelements of contributor.

Admitted, nothing in the documentation claims that the numbering of subproperties would indicate the proper order to produce the elements in the XML file. But it is at least unfortunate to suggest a wrong order by the numbering.

change <br> in XDS for version 4.2

I forward an issue on behalf of a client who encountered some difficulties and misunderstanding related to the Description field and the use of the
field/code therein. Of course, I already explained that “br” is not a real input field and should be empty. It’s stated in the XSD as:

Front conversations

make html pages valid

add tests for oai schema

schemaLocation in example should be fully qualified

Currently it is:

xsi:schemaLocation="http://schema.datacite.org/oai/oai-1.0/ oai_datacite.xsd"

it should be:

xsi:schemaLocation="http://schema.datacite.org/oai/oai-1.0/ http://schema.datacite.org/oai/oai-1.0/oai.xsd"

Schema 4.2 XSD

HTML version of schema 4.2 documentation

Add "XML:lang" attribute to title and description

Typo in Table 4, Property 12

There is a typo in the documentation of the schema in Table 4 Expanded DataCite Recommended and Optional Properties for Property 12.2 relationType: the column Allowed values, examples, other constraints contains a controlled list of values. One of these values reads IsDescribed by. I believe, it should rather read IsDescribedBy (note the embedded space and the small "b" in "by").

import datacite logo

linking to api.datacite.org is not a good idea

JSON schema: geoLocationPolygons

the JSON schema allows a geoLocationPolygons arrray to consist of a single inPolygonPoint. Is this intentional to distiguish a point-located resource from a polygon-located resource for which only the polygon centroid is reported?

namespace for schema

Do we want to have namespace for oai schema analogue to our other schema? This would mean "http://datacite.org/schema/<...>" instead of "http://schema.datacite.org/<...>".

DataCite Schema 4.3

Update XSD, examples, tests, and schema website for schema 4.3. Changes include:

Addition of optional "affiliationIdentifier", "affiliationIdentifierScheme", and "schemeURI" for affiliation
Addition of optional "schemeURI" for funderIdentifier
Addition of "ROR" to allowed values for funderIdentifierType

purpose of LastMetadataUpdate and MetadataVersionNumber?

From the current documentation:

In addition to the metadata that submitters supply with registrations and updates, there are two
administrative metadata properties that the managing agency will assign to each DataCite metadata
record, shown in Table 3. These properties convey the date on which the metadata description was
stored by DataCite (LastMetadataUpdate) and a sequence number assigned to the metadata
description by DataCite (MetadataVersionNumber).

This is not what we're currently doing. We do have such fields in MDS, but directly in the database. We do not fill the fields in the metadata itself atm and this is not planned. We have to discuss if we really need it inside the metadata or not... At least it led to some confusion, because the documentation is inaccurate.

If you use OAI to harvest our metadata, there is a timestamp field holding the value of our LastMetadataUpdate. So it can be used, although it is not in our metadata directly.