GoTriple Content Providers Handbook
V1.0, January 2023

Table of content
Purpose of this document ............................................................................................................................. 1
GoTriple Policies .............................................................................................................................................. 2
Scope...................................................................................................................................................................................... 2Content types ..................................................................................................................................................................... 2
GoTriple Requirements ................................................................................................................................. 3
Technical set-up................................................................................................................................................................ 3
GoTriple data model ....................................................................................................................................................... 4Best practices for contents’ visibility ........................................................................................................ 6
Metadata quality ............................................................................................................................................................... 6
FAIR principles.................................................................................................................................................................. 9Aggregators ..................................................................................................................................................................... 10
Process and support .....................................................................................................................................12
Harvesting management system ............................................................................................................................ 12
Data dumps ingestion ................................................................................................................................................. 12
Credits................................................................................................................................................................12
Annexe ...............................................................................................................................................................13
Glossary ............................................................................................................................................................................. 13
GoTriple list of content types................................................................................................................................... 13
List of licenses supported on GoTriple ................................................................................................................ 14
Sample metadata files ................................................................................................................................................. 14
OpenAIRE JSON file format ....................................................................................................................................... 18

Purpose of this document
GoTriple is a discovery service for scientific outputs in the Social Sciences and Humanities
area. It is one of the services of the European Research Infrastructure OPERAS.
The GoTriple platform allows to search through publications, datasets, researchers’ profiles,
and research projects. Publications and datasets metadata are collected from both content
aggregators and content providers (see Glossary).
This handbook is addressed to the GoTriple content providers. It presents the policies,
technical requirements, and supporting actions enabling the providers’ content acquisitionand processing by the GoTriple platform. It informs them as well about other aggregators’
policies.

GoTriple Policies
Scope
Scientific fields: GoTriple collects metadata of contents in the Social Sciences andHumanities (SSH) field (see Content types section). The content providers can be domain
specific or not. In case they are not dedicated to SSH, the content providers are responsible
for selecting SSH contents in their collections.
Data definition: GoTriple only collects metadata of the contents. The platform does notcollect or store the contents of the providers.
Perimeter: GoTriple operates in the European area and provides enrichments for a limited
number of European languages. Therefore, the platform mainly collects data from European
providers and in European languages. However, it can also collect data from other geographic
and linguistic areas.
Openness: As a service of OPERAS, the Research Infrastructure dedicated to open scholarly
communication in the SSH, GoTriple promotes open access to the contents. Openness applies
to datasets (open data) and publications (open access). The platform however collects open
and not open access contents. The metadata of the contents need to be freely accessible andreusable.
Providers type: GoTriple providers can be of any size and provide large or small amount ofcontents in one or many SSH fields. GoTriple works with major aggregators, but also
facilitates data acquisition from small repositories or publishers, like for instance diamondjournals.
GoTriple supported languages: GoTriple provides enrichments of the metadata in thefollowing languages: Croatian (HR), English (EN), French (FR), German (DE), Greek (EL),
Italian (IT), Polish (PL), Portuguese (PT), Slovenian (SL), Spanish (ES), Ukrainian (UK). The
platform however accepts contents in any language.
Content types
This handbook only considers the data collected on scientific resources. Data on researchers’
profiles and research projects are collected through distinct automated processes.
In GoTriple, the resources are publications and datasets, which are all named “documents”.
A document is the information asset, i.e. a series of metadata, of a unique and deduplicatedresource (see Glossary).
The list of content types available on GoTriple is based on a subset of the COAR list of types(see Annexe).
On GoTriple, publications are any type of text or material related to the SSH research
environment, from articles or thesis, to reports or learning material. As for the datasets, they
are a set of organized research data. In the context of GoTriple, these resources are only

indexed at the level of the collection. Each single file of the datasets is therefore not indexed.
The level of collection harvestable by GoTriple will be assessed for each data source.

GoTriple Requirements
In order to have their contents collected by GoTriple, the providers essentially have torespect two requirements: providing an access to their metadata and providing metadata
compliant with the platform’s data model.
The providers can have their contents indexed on GoTriple in three ways: - by following the
GoTriple recommendations for the technical set-up and the data model, i.e. using the OAIPMH protocol and the DC metadata standard. - by sending a metadata file to the GoTriple
administrators using the OpenAIRE format (see Annexe). - by having their contents on one of
the aggregators of GoTriple (currently: DOAB, DOAJ, Isidore and OpenAIRE): in this case, thecontent will be automatically collected by GoTriple.
The first option ensures that the metadata is easily processable and can be regularly updated
in an automated way.
The second option allows to provide metadata compliant with the GoTriple data model
without using the OAI-PMH protocol. This solution however hinders automated dataacquisition and updates.
The third option does not require any action from the providers if their content is alreadyindexed by the listed aggregators, and if not, requires them to follow the aggregators specificguidelines (see Aggregators section).
The following two sections specify the technical set-up enabling GoTriple to automaticallyaccess the metadata and the model that these metadata should follow.
Technical set-up
GoTriple collects data by using the Open Archive Initiative - Protocol for Metadata Harvesting(OAI-PMH). The OAI-PMH protocol was developed in 1999 as part of the Open Archives
Initiative. It allows content providers to expose their metadata on the Web in a structured
format and to make it available for harvesters. The repository is set-up by the provider andcontains sets of metadata.
The metadata has to be represented according to the simple DublinCore standard at least,
which uses dc elements that are described in the Dublin Core Metadata Element Set. A richer
version of DC also exists, which uses dcterms elements and is described in the DCMI Metadata
Terms. This version contains both simple Dublin Core (DC) and qualified Dublin Core (QDC).
The OAI-PMH allows harvesters like GoTriple to then collect the structured metadata. DC and
QDC can be expressed in XML, HTML, XHTML or JSON files, although GoTriple only collects
dc and dcterms elements in XML format. GoTriple also has an experimental support ofharvesting OAI-PMH endpoints that expose metadata according to the Europeana Data Model(EDM).

The OAI-PMH repository can be set up by the content provider with little development
investment. Some tools and services for data repositories or publishers can contain an OAIPMH module, either as a built-in feature or a plugin (e.g. DSpace, Eprints, OJS).
A list of open source tools to set up an OAI-PMH repository is available on the website of theOpen Archive Initiative.
In the case of metadata provided through dedicated files, the publisher must periodicallyprovide to GoTriple administrators a file export of their publications’ metadata in the
OpenAIRE format (see Annexe). The import procedure is not therefore completely
automated and needs a certain number of human interactions. It is requested to provide atleast two full export files per year per publisher via some file transfer method (http, ftp, cloud
sharing, etc).
GoTriple data model
In order to ensure high semantic expressivity and address flexibility needs, the TRIPLE data
model is based on the schema.org ontology, which is maintained by a World Wide Web
Consortium (W3C) community. The ontology allows to handle the metadata of documents,
but also of profiles and projects.
When it is collected through OAI-PMH, the metadata of the documents need to be compliant
with DublinCore, simple or qualified, ie using dc or dcterms elements. When metadata iscollected through formatted files, it is possible to use other schemas, like the aforementioned
OpenAIRE format. Examples of the file both in DC and in OpenAIRE format are reproduced in
Annexe).
Below, we describe the current TRIPLE data model for documents, specifying the level ofpriority, the corresponding dc and dcterms elements, and their expression in the TRIPLE data
model.
Priority
Mandatory
Mandatory
Mandatory
Recommended

Description
Creator of theresource
Identifier ofthe resource
Title of theresource
Abstract

Access rights
to the resource
Date of
Recommended
publication or
creation
Recommended

DublinCore
dcterms:creator,
dc:creator
dcterms:identifier,dc:identifierdcterms:title, dc:title

Triple data model
schema:author

dcterms:description,
dc:description,
dcterms:abstract
dcterms:rights, dc:rights

schema:abstract

dcterms:date, dc:date,dcterms:issued,

schema:identifier
schema:headline

schema:conditionsOfAccess
schema:datePublishedPriority

Description

Recommended

Keywords

Recommended

Language ofthe resource
LicenseRecommended
Recommended
Recommended
Recommended
Recommended
Recommended

Optional

Optional
Optional

Optional

Optional

Publisher ofthe resource
Type of theresource
URL of thelanding page
URL of theresource
URL of thesource(e.g. URL of apublishingplatform)
Contributor to
the resource’s
creation
Format of theresource
Information on
the source(e.g. journal
issue)
Temporalcoverage of theresource
Spatialcoverage of theresource

DublinCore
dcterms:created,dcterms:available
dcterms:subject,dc:subject
dcterms:language,
dc:language
dcterms:license OR
dcterms:rights, dc:rights
dcterms:publisher,
dc:publisher
dcterms:type, dc:type

Triple data model

schema:keywords
schema:inLanguage
schema:license
schema:publisher
schema:additionalTypedcterms:identifier
dc:identifierdcterms:identifier
dc:identifierdcterms:source,
dc:source

schema:mainEntityOfPage

dcterms:contributor,
dc:contributor

schema:contributor

dcterms:format,
dc:format
dcterms:source,
dc:source

schema:encodingFormat

dc:coverage,
dcterms:coverageschema:temporalCoveragedcterms:spatial

schema:spatialCoverageschema:url
schema:isBasedOnURL

schema:mentions

Priority.
The mandatory elements are necessary for the platform to process the metadata. The
recommended elements increase both the findability of the contents and the quality of theautomated processes run by the platform. The optional elements can provide additional
information useful for the users.
DublinCore elements.
The simple DC elements are introduced by the dc namespace, the qualified DC elements are
introduced by the dcterms namespace. While it is still technically possible to use dc elements,
it is preferable to use dcterms elements, which allow for a more detailed description of theresource.
In some cases, it is possible to use one or many DC elements to describe an aspect of theresource: the date of the resource can be described through dcterms:date or through themore accurate dcterms:created and dcterms:available.
TRIPLE data model.
The elements of the TRIPLE data model in the schema.org ontology are reported only for
information: these are handled only by the GoTriple platform, not by the content providers.
Some of the DC and QDC elements are processed by the platform. This is especially the casefor “URL of the landing page” and “URL of the resource”, which are automatically determinedfrom the content of dcterms:identifier or dc:identifier. The TRIPLE data model also
contains a few other elements for documents that are created through the analysis of themetadata files.

Best practices for contents’ visibility
Metadata quality
While only three metadata elements are technically mandatory on GoTriple, richer metadata
improves the processing by the information systems and therefore increases the visibility of
the contents. However, some of the metadata elements require more accurate management
in order to fully exploit the potentialities of the DublinCore standard. We list below a few
hints able to improve the metadata quality in the context of GoTriple, but also in the context
of other aggregators, like OpenAIRE, DOAJ, DOAB or BASE.
Priority
Mandatory

Description
Creator of theresource

Mandatory

Identifier ofthe resource

Hints and comments
Can contain one or many creators of the resource andcan be individuals or organizations. On GoTriple,
person names undergo a normalization process able toimprove the filtering.
Can contain one or many identifiers of different types.
Identifiers are non semantic strings of characters
uniquely identifying a resource. They should belong toa well-known identification system (e.g. ISBN, DOI,
handle.net, etc.). In the digital context, the more
important identifier is the Persistent Identifier (PID),
which ensures the identification of the resource
throughout the various digital locations. PersistentPriority

Description

MandatoryTitle of theresource
Abstract

Recommended

Recommended

Access rights
to theresource

Recommended

Date ofpublication or
creation

Recommended

Keywords

Recommended

Language ofthe resource

Recommended

LicenseHints and comments
identifiers include among others: DOI from Datacite or
Crossref, handles from handle.net.Identifiers should be
provided as HTTP links and can be specified throughdedicated encoding schemes accepted by the DC
standard (e.g. URI).
Titles are used for automated enrichments on GoTriple.
They shouldn’t be or contain a file name.
The dcterms:description can be more extended thanthe dcterms:abstract, or contain an abstract. On
GoTriple, abstracts are used for the automatedsemantic classification and annotation.
On GoTriple, this information is retrieved exclusively
from dc:rights or dcterms:rights elements. Notethat a specific dcterms:accessRights also exists. Can
contain free text information specifically about theaccess to the resource. As recommended also by
OpenAIRE, it is possible to specify the access type in anormalized way through the COAR access rights types:
embargoed access; metadata only access; open access;restricted access. Access information can becomplemented with licensing information.
Without more precise information, the dcterms:dateor dc:date element will be interpreted on GoTriple as“resource’s first release date”. Although the dateelement is normalized on GoTriple, it is preferable touse standardized date formats, like for instance ISO
8601. Date or period related not to the resource, but toits content, should be indicated in dcterms:coverage.
Can contain one or many keywords describing thecontent of the resource. In DC, the keywords language
can be specified using an xml:lang attribute. The XML
specification prescribes the usage of language
identifiers as defined by IETF BCP 47 for values of this
attribute. In the context of GoTriple it is mandatory tousegeneral, using the ISO 639-1 two-letter code.
Describes the language in which the resource isexpressed. Like for keywords, for GoTriple, it ismandatory to use the ISO 639-1 two-letters code.
A legal document indicating how the resource can beaccessed and used. In QDC, there is a specific element
for the licensing information: dcterms:license, but it
is also possible to use dcterms:rights, dc:rights as
an alternative. This element can also containPriority

Description

Recommended

Publisher ofthe resource

Recommended

Type of theresource

Recommended

URL of thelanding page

Recommended

URL of theresource

Recommended

URL of thesourceOptional

Contributor to
the resource’s
creation

Optional

Format of theresource

Hints and comments
information about copyright and intellectual property
rights. While a license can be a free text, it is preferable
to use standardized licenses: they are easier tounderstand for humans and can facilitate machinereadability. In the context of open science, especially, it
is recommended to use well-spread open licenses, forexample Creative Commons (CC) licenses. The CC
licenses allow to indicate an URL and to indicate thelicense type in a simple way. See the list of licenses
supported by GoTriple in Annexe.
An entity responsible for making the resource
available. Can be a person, an organization, like apublishing company or a service, like a data archive.
The publisher element describes the resource and its
production, not the creator and its affiliations.
The type of the resources should refer to a well-spreadtaxonomy, like the aforementioned COAR list of types,
or the subset of COAR types used by GoTriple and listed
in Annexe.
The URL of the landing page can be indicated as a
specific dcterms:identifier or dc:identifier
element using the URI scheme. Should contain an HTTP
link without a .pdf extension
Like the URL of the landing page, the URL of theresource itself can be indicated as a specificdcterms:identifier or dc:identifier element using
the URI encoding scheme. In GoTriple, the URLs listed
in the identifier elements containing a .pdf extension
are used to create the direct link to the full text.
A related resource from which the described resource
is derived. In GoTriple, dcterms:source and dc:source
elements are used to refer to the publishing platform
or data repository if it contains an HTTP link without a.pdf extension.
An entity responsible for making contributions to theresource. Other than the entities that have contributed
to the creation of the resource (e.g. a data scientist for adataset, an editor for a publication), the contributor
element can be used to list the organizations that havemade the creation possible.
The file format, physical medium, or dimensions of theresource. Recommended practice is to use a controlled
vocabulary where available. For example, for filePriority

Description

Optional

Informationon the source
Temporalcoverage ofthe resource

Optional

Optional

Spatialcoverage ofthe resource

Hints and comments
formats one could use the list of MIME Internet media
typesThis element is used for instance to indicate therelation of an article with a specific journal issue.
In the DublinCore standard, dc:coverage anddcterms:coverage contain information about temporaland spatial coverage. In GoTriple, these elements areused only for the temporal coverage. Spatial coverage
should be indicated in dcterms:spatial .
Contains free or standardized text about the spatial
area considered by the resource. The element is only
available in QDC: dcterms:spatial .

FAIR principles
The FAIR principles emerged in 2016 from an interdisciplinary group of research dataexperts. The acronym FAIR refers to four guiding principles for digital data management:
making the data Findable, Accessible, Interoperable, and Reusable. The FAIR principles
address the need for a common understanding of data management good practices able tofacilitate data sharing and reuse. Although the principles mainly consider technical aspects,
they allow, as principles, to adapt the concrete implementations to specific contexts. In
particular, they can apply to any research digital object: datasets, publications, software, etc.
The four ground principles are further described in a set of fifteen principles. GOFAIR, theorganization supporting the FAIR principles adoption, gives detailed information about the
fifteen FAIR principles. The OPERAS Special Interest Group on “Common standards and FAIR
principles” also provided an overview in its 2021 White paper.
The FAIR principles are a useful tool to manage digital data in a way that facilitates bothhuman and machine operations. They have been used to build the TRIPLE data model andare now at the core of all major aggregators practices.
The Findability principle relies mainly on the use of persistent identifiers and richdescriptive metadata. The metadata should give information about the resource, like: creator,
title, persistent identifier, publisher, publication date, abstract and keywords. A
counterexample is a corpus stored on a USB device with descriptive information only in thefile name.
The Accessibility principle relies on the use of open, free and documented protocols, such as
HTTP, OAI-PMH, FTP, even if they are combined with authentication processes. Accessibility
is further improved if metadata gives information about the conditions of access. A
counterexample is the data exchanged through emails on individual request.
The Interoperability principle relies on the use of standard representation of the data, likethe DublinCore schema aforementioned. Interoperability can also be reached thanks todocumented controlled vocabularies shared within a broad community. A counterexample isa dataset described according to an individual and not documented vocabulary.
The Reusability principle relies on clear licensing information, as liberal as possible,
preferably standard and recorded in the metadata. It should be completed with clear
provenance information, which allows to better assess the reusability possibilities. A
counterexample, without mentioning the lack of any license, is a license containing unclear
conditions of use in a separate PDF file.
The TRIPLE data model follows the main aspects of the FAIR principles and this handbook
will help you to ensure that your content is Findable, Accessible, Interoperable, and Reusable.
Aggregators
GoTriple harvests metadata from major European aggregators and the TRIPLE data model isglobally compliant with their own data models. Your content can therefore appear on
GoTriple if it is already indexed by our current partner aggregators: DOAB, DOAJ, Isidore and
OpenAIRE. Furthermore, if the content provider doesn’t have an OAI-PMH repository,
GoTriple can ingest metadata files formatted according to the OpenAIRE format (seeAnnexe).
However, with respect to the TRIPLE data model, each aggregator may have additional
requirements. We list below some information about these requirements for the main
aggregators that are useful for the SSH research community.
Here is the list of aggregators currently harvested by GoTriple:•

DOAB (harvested by GoTriple).

DOAB is a community-driven discovery service that indexes and provides access to scholarly,
peer-reviewed open access books.
The current main requirements to provide content in DOAB are twofold:
1/ Academic books in DOAB shall be available under an open access licence (such as a
Creative Commons licence).
2/ Academic books in DOAB shall be subjected to independent and external peer review prior
to public.
From a technical point of view, the requirements are specified in a separate document.
Although the TRIPLE data model is globally compliant with the DOAB data model, the latter
contains information specific to monographs. The DOAB also handles an OAI-PMH
repository, but the content provider can send the metadata through a form or a file, without
using DublinCore or an OAI-PMH repository.
•

DOAJ (harvested by GoTriple).

As their website reads, DOAJ is an independent index containing almost 17 500 peerreviewed, open access journals. The DOAJ covers all areas of science, technology, medicine,social sciences, arts and humanities, with open access journals from all countries and in all
languages.
The criteria for the journals are the following:
1/ The journal must be actively publishing scholarly research.
2/ Publish in any research subject area.
3/ Should publish at least 5 research articles per year.
4/ Its primary target audience should be researchers or practitioners.
For newly launched journals, an additional requirement applies: it must demonstrate apublishing history of more than one year, or have published at least 10 articles.
The DOAJ doesn’t require to have an OAI-PMH repository. There are various ways to upload
metadata about articles to DOAJ. It is possible to send JSON files via their API (seedocumentation). It is also possible, once the journal has been accepted to use a dedicatedspace to send metadata in an XML file or to enter it manually. The DOAJ provides anapplication guide for the journals publishers. More details about the DOAJ’s data model forjournals and articles can be found on this page. DOAJ is harvested by the main aggregators,
including GoTriple. As the DOAJ does not require to set up an OAI repository, it offers
therefore a good solution for content providers who do not have an OAI repository available.
•

Isidore (harvested by GoTriple).

Isidore is a French platform dedicated to social sciences and humanities scientific outputs. It
contains over than 10 millions documents, ranging from publications to data (full list oftypes). Isidore has the specificity to offer high quality automated enrichments in threelanguages (ENG, FRA, SPA) aligned with major authority databases (e.g. RAMEAU, LCSH,
BNE) and exposed in a structured way compliant with semantic web requirements. Isidore
served as a basis for the building of GoTriple.
Isidore relies on the OAI-PMH protocol to retrieve data. Although enrichments are proposed
only in three languages, the platform can harvest contents in any language. At present, it
collects metadata from a variety of publishing platforms, archives, and repositories in Europe
and beyond. The data sources are listed in the documentation (French only).
In order to have contents harvested by Isidore, it is required to have a valid OAI-PMH
endpoint and provide simple or qualified DublinCore metadata. The guidelines for metadatamanagement provided by the DublinCore Metadata Innovation group are applicable for the
harvesting by Isidore.
Any repository or publisher interested in being harvested by Isidore should contact directly
the administrators of the platform using this email address: isidore-sources(at)huma-num.fr.
•

OpenAIRE (harvested by GoTriple).

Among other services, OpenAIRE offers a discovery service for millions of research outputs:
publications, datasets, software and other research products. Although mostly referencing
contents produced in the European area, OpenAIRE also accepts contents from outside

Europe.
GoTriple harvests from OpenAIRE a subset of publications and datasets in the SSH area.
OpenAIRE relies on the OAI-PMH protocol to retrieve data. The protocol allows OpenAIRE to
harvest data from the zenodo repository and from the research data repositories listed by
re3data. It is therefore possible to be harvested by OpenAIRE and indexed on their platform
Explore, by having the content stored in one of these repositories.
It is also possible to become a content provider for OpenAIRE. Besides the requirement tohave an operational OAI-PMH endpoint, becoming a content provider requires to respectthese two main requirements:
1/ Having your repository registered on OpenDOAR.
2/ Following the OpenAIRE guidelines to establish your metadata.
The OpenAIRE metadata guidelines depends on the type of digital content:- Guidelines for Literature, institutional, and thematic Repositories. - Guidelines for Data
Archives. - Guidelines for Software Repository Managers. - Guidelines for Other Research
Products.
More information about OpenAIRE’s content policy can be found in the dedicated section of
their website, especially the Terms of Use document which has to be reciprocally accepted
by OpenAIRE and the content provider.

Process and support
Harvesting management system
Content providers interested in being harvested by GoTriple should first check the GoTriple
policies and requirements described in this document (see GoTriple policies and GoTriple
requirements).
Providers fulfilling the GoTriple prerequisites, i.e. having installed an OAI-PMH repository
with standard Dublin Core metadata available, have to use the dedicated service of GoTriple,
the Harvesting Management System (HMS). The HMS allows you to register as a GoTriple
data provider, indicating your institution and your OAI-PMH URL, to interact with the
GoTriple admin team, and to follow the harvesting process of your contents.
Data dumps ingestion
The data providers who would like to send database dumps structured according to the
OpenAIRE format should follow the recommendations about the OpenAIRE JSON format inAnnexe and contact the GoTriple admin team by clicking the “Report an issue” button at thebottom left of the GoTriple home page (https://www.gotriple.eu/).

Credits
The GoTriple platform and this handbook have been created through the project TRIPLE(Transforming Research Through Innovative Practices for Linked Interdisciplinary
Exploration).

TRIPLE has received funding from the European Union’s Horizon 2020 Research andInnovation action funding scheme INFRAEOSC-02-2019 “Prototyping new innovative
services” (grant agreement #863420).

AnnexeGlossary
Aggregator
An organization that collects, manages, and disseminates the metadata of the scholarly
resources’ made available by various providers. The aggregator operates as a standardisationbody of heterogeneous metadata, either by defining its own requirements, or by relying on
existing standards for harvesting and dissemination.
Core pipeline
The back-end system of the TRIPLE infrastructure that takes care of acquiring, normalisingand semantically enriching data from multiple sources.
Dataset
On GoTriple, corresponds to a collection of files produced within a research project foranalysis and processing. A dataset can contain files of various types (surveys, recordings,
images, measures, etc.) and formats (video, audio, spreadsheets, etc.).
Document
Refers to the information asset related to a specific digital object; it is used to identify single
scholarly resources such as publications and datasets. On GoTriple, a document corresponds
to the set of metadata, collected or generated, describing a scholarly resource.
Harvester In the context of OAI-PMH, the Open Archive Initiative - Protocol for Metadata
Harvesting, a harvester is the entity collecting automatically metadata exposed in an OAIPMH repository. Harvesters can collect metadata from many providers, in which case theharvesters can be defined as aggregators.
ProviderAn organization that manages, collects, and disseminates scholarly resources. It operates as
the manager of one or various data repositories, archives, or publishing platforms. A provider
enriches the data it is responsible for with metadata facilitating its dissemination, and acts as
the primary dissemination body of the data and its metadata.
Publication On GoTriple, a publication is a textual object formatted for dissemination andproduced in the context of research. A publication can be of various types (article, book,report, training, etc.) and formats (pdf, epub, presentation, etc.).
GoTriple list of content types•
article (COAR type)•bibliography (COAR type)•blog-post (COAR type)

•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

book (COAR type)conference (COAR type)dataset (COAR type)image (COAR type)learning-object (COAR type)manuscript (COAR type)
report (COAR type)
periodical (COAR type)preprint (COAR type)review (COAR type)software (COAR type)text (COAR type)thesis (COAR type)map (COAR type)other (COAR type)

List of licenses supported on GoTriple
GoTriple will provide normalization for a a limited set of widely used set of licenses. Here is
the list of the supported licenses: - Cairn - Creative Commons - OpenSource licenses(including apache, gpl, bsd, mit licence) - CLARIN PUB, CLARIN ACA, CLARIN ACA-NC,
CLARIN-RES, CLARIN RES-NC - Microsoft Public Licence - Microsoft Reciprocal Licence Open Data (ODbL, Open Data Commons Open Database Licence) - META-SHARE No
Redistribution, META-SHARE NonCommercial NoRedistribution, META-SHARE Commercial
No Redistribution For a Fee, META-SHARE Noncommercial No Redistribution For a Fee ELRA licenses - other licenses will be marked as “other” if not recognized, or “undefined” if
the license is not specified
Sample metadata files
Below are displayed two examples of the files used on the GoTriple platform: one in the XML
Dublin Core format, one in the JSON OpenAIRE format.

XML DC example:

JSON OpenAIRE example:

OpenAIRE JSON file format
The
OpenAIRE
JSON
schemasforpublicationsareavailable
here
https://zenodo.org/record/5799514#.YtAAYOxBw40. The specific schema used by GoTriple
is: https://zenodo.org/record/5799514/files/result_schema.json?download=1.
In GoTriple we only consider the following subset of elements, which must be included in the
dump produced for the import in our platform:

Description
Creator of theresource
Identifier of theresource
Title of theresource
Abstract
Access rights to
the resource
Date ofpublication or
creation
Keywords
Language of theresource
LicensePublisher of theresource
Type of theresource
URL of thelanding page
URL of theresource
URL of thesource (e.g. URL
of a publishingplatform)
Contributor to
the resource’s
creation
Format of theresource
Information on
the source(e.g. journal
issue)

JSON schema
author/fullname

Triple data model
schema:author

id

schema:identifier

maintitle

schema:headline

description
bestaccessright/label
publicationdate

schema:abstractschema:conditionsOfAccess
schema:datePublishedsubjects/subject/value (Only if
subjects/subject/scheme=keyword )language/code

schema:inLanguage

instance/license
publisher

schema:license
schema:publisher

instance/type

schema:additionalType

instance/url (it must start with http andmust not end with .pdf)
instance/url (it must start with http andend with .pdf)
we consider the element: originalId (itmust start with http)schema:mainEntityOfPage

contributor

formatwe consider the element:collectedfrom/key (it must not startwith http)schema:keywords

schema:url
schema:isBasedOnURL

schema:contributor

schema:encodingFormat
schema:mentions

Description
Temporalcoverage of theresource
Spatial coverageof the resource

JSON schema
null

Triple data model
schema:temporalCoveragecoverage

schema:spatialCoverage