Contribute a non-ELG compatible tool or service¶
This page describes how to contribute tools or services that do not follow the ELG specifications to the European Language Grid. These include downloadable tools that run locally, web services running outside ELG, etc.
You can describe a tool or service and upload its contents at ELG or include in its description a link to the location it can be accessed from.
0. Before you start¶
1. Prepare the content files (for ELG hosted resources)¶
If you wish to upload the software (e.g. software code, downloadable executable files that run locally, docker images) at ELG, you must package it in a compressed format (currently as a .zip file).
2. Describe and register the software at ELG¶
You can describe and register the tool or service
using the the ELG interactive editor (see Use the interactive editor), or
If you wish to upload the software, follow the instructions described here.
In both modes, you MUST indicate that it is NOT an ELG compatible service. More specifically, if you use the interactive editor, select the Service or Tool form and, when prompted, select No.
If you decide to upload a metadata file, you MUST NOT check the box next to ELG-compatible service at the upload page.
The following figure gives an overview of the metadata elements you must provide 1 for a tool or service that is not ELG-compatible, replicating the editor (with sections horizontally and tabs vertically) so that you can easily track each element. In the editor, all elements, mandatory or not, are explained by definitions and examples.
To describe any resource efficiently you need to name it, provide a description with a few words about it and indicate its version 2. Then, one or more keywords are asked for the resource and an email or a landing page for anyone who wishes to have additional information about it.
For tools or services, you must also specify the function (i.e., the task it performs, e.g. Named Entity Recognition, Machine Translation, Speech Recognition, etc.) and supply the technical specifications of its input, at least the resource type it processes (e.g. corpus, lexical/conceptual resource etc.). You must also select whether it is language independent and, if not, specify the input language(s). Depending on the function, you may be required to add further information, e.g. the language of the ouput resource for Machine Translation services.
You also have to describe independently each distributable form of the service (i.e. all the ways the user can obtain it, e.g., as a docker image, or as a web service). For each distribution, you must always specify the licence under which it is made available. You must also specify the software distribution form and, in case you decide not to upload the content files at ELG, include a link to the point it can be accessed from (download / docker download / access / distribution location 3) or, in the case of web services, the execution location. Finally, for web services, you must add the web service type (eg. REST).
3. Manage and submit for publication¶
Through the My items page you can access your metadata record (see Manage your items) and edit it until you are satisfied. You can then submit it for publication, in line with the publication lifecycle defined for ELG metadata records.
At this stage, the metadata record can no longer be edited and is only visible to you and to us, the ELG platform administrators.
Before it is published, your submission undergoes a validation process, which is described in detail at CHAPTER 4: VALIDATING ITEMS.
Once approved, it will appear on the ELG catalogue and you will receive a notification email.
You must fill in at least the mandatory elements for the metadata record to be saved. In addition, you may be required to fill in specific mandatory if applicable elements (indicated in the figure with an asterisk), depending on the values you provide for other elements.
If no version number is provided, the system will automatically number it as “1.0.0” with an indication that it has been automatically assigned. We recommend, however, the use of Semantic Versioning (https://semver.org/) for labelling versions.
The four elements differ in terms of the actions that a consumer has to undertake in order to access the resource. Use download location to provide a direct link to the content files; no actions are required on behalf of the user who can simply download the file(s). Docker download location is intended for the location where the docker image resides and can be pulled by the user. Access location is typically a page with some text, which includes a button or a link for accessing or downloading the resource itself; the user must read through the text on the page in order to find the link. Finally, distribution location is reserved for distributable forms in formats, such as CD-ROM, or hard disks, for which the user must engage in a transaction with the provider to gain access to the resource.