Add your own Repository¶
If you like to add your (institutional) repository, please get in contact with us. On this page we offer you some information about our services and what has to be done on your side.
Currently we work on implementations for EPrints, MyCore and DSpace.
Currently we support the SWORDv2 protocol. However, this protocol offers a lot of options about how to deposit and how to organize the metadata and should be seen as a framework. Technically we can offer different depositing methods, e.g. via some REST API or similar.
Shipping with SWORDv2¶
We use the Metdata Encoding & Transmission Standard (METS) to ship our metadata and describe what is delivered. Most repositories are able to ingest a METS-package.
We try to keep our METS as simple as possible.
Currently we populate only
dmdSeccontains the bibliographic metadata
amdSec/rightsMDcontains information about the depositor, the license and additional dissemin related information. You find the documentation in Dissemin Metadata.
We deliver two files per package:
mets.xml- containing the metadata
document.pdf- the document to be deposited
We provide an
illustrating example using Dublin Core.
We set the following headers:
Content-Type: application/zip Content-Disposition: filename=mets.zip Packaging: http://purl.org/net/sword/package/METSMODS
If you require for your ingest a different packaging name or packaging format, please let us know.
The body is the named file. All values won’t change between different uploads to the same repository.
Script for Tests¶
To support you in your local implementation we have some examples (grouped by document type, see below). This is authentic metadata, i.e. this metadata was created by Dissemin and represents how the metadata documents will loke like.
You can download our
script for testing your implementations.
The HTTP-requests are identical to those in Dissemin.
You find usage instructions in the README.md inside of the packaging.
Most of our data comes from CrossRef and has thus a certain quality.
We offer currentlry Metadata Objects Description Data (MODS).
Currently we create version
We populate as near as the definitions require as possible.
You find below our mappings using XPath notation.
abstract => abstract author => name[@type="personal"]namePart/given + family + name author[orcid] => name/nameIdentifier[@type=orcid] date => originInfo/dateIssued[@enconding="w3cdtf"] (YYYY-MM-DD) ddc => classification[@authority="ddc"] document type => genre doi => identifier[@type="doi"] essn => relatedItem/identifier[@type="eissn"] issn => relatedItem/identifier[@type="issn"] issue => relatedItem/part/detail[@type="issue"]/number journal => relatedItem/titleInfo/title language => language/languageTerm[@type="code"][@authority="rfc3066"] pages => relatedItem/part/extent[@unit="pages"]/total or start + end publisher => originInfo/publisher title => titleInfo/title volume => relatedItem/part/detail[@type="volume"]
Note that volume, issue and pages are often not arabic numbers, but may contain other literals. Although MODS does provide fields for declarations like No., Vol. or p. we do not use this, because our datasources don’t.
We ship the language as rfc3066 determined by langdetect. We ship the language if both conditions are satisfied:
- The abstract has a length of at least 256 letters (including whitespaces)
langdetectgains a confidence of at least 50%
If we cannot determine any language, we omit the field.
Optionally we ship the Dewey Decimal Class (DDC).
We support up to the first 1000 classes, i.e. from
You can freely chose which classes are of interest.
When presenting the user, we group them with categories
We ship the classification number as three-digit-number, i.e. filling up with leading zeros for numbers smaller than 99.
This is our list of examples of MODS metadata created by Dissemin. This includes, that they are already contained in a suitable METS container. The list is sorted by publications types and covers all publication types that Dissemin uses.
In addition to our bibliographic metadata we ship special dissemin metadata. This metadata is meant to support publication workflows in institutional repositories, for example helping in the moderation process.
We ship the following data:
|authentication method||The method of authentication. This is currently shibboleth and orcid.|
|name||The first and last name of the depositor. Note that the depositor does not need to be a contributor of the publication.|
|E-Mail address of the depositor in case you need to contact them.|
|orcid||ORCID if the depositor has one.|
|license||The license. Most likely Creative Commons, but different licenses are possible. We happily add new licenses for your repository. We deliver the name and if existing URI and a transmit id.|
|SHERPA/RomeoID||ID of the journal from SHERPA/RoMEO. Using their API or web interface you can quickly obtain publishers conditions.|
|DisseminID||This ID refers to the publication in Dissemin. This ID is not persistent. The reason is the internal data model: Merging and unmerging papers might create or delete primary keys in the database. For a ‘short’ period of time, this id will definetely be valid. You can use the DOI shipped in the bibliographic metadata to get back to the publication in Dissemin.|
If you need more information for your workflow, please contact us. We can add additional fields.
You can find our schema for
download in Version 1.0.