Depending on the software you use for automatic text recognition, the output options may vary. The two main types of export, **plain text** and **layout**, are usually met in every one of them, as one or multiple formats.  

Plain text is the simplest export of a transcription, as it only provides the text that was either manually transcribed, or predicted and corrected. Plain text formats are ```.txt``` or ```.docx``` (Microsoft Word).  

The layout export preserves all the information gathered during the whole process of automatic recognition: metadata, regions, lines, masks, text, and some additional annotations when the tools allow. The layout export provides an encoded version of the transcription, but depending on the format, the markup language is not the same:
* HTML: ```hOCR``` 
* XML: ```PAGE``` and ```ALTO``` 

```PDF``` is a third type of export. It represents plain text with layers, which means that the image is now available in a PDF format and the segmentation or text recognition is available as layers embedded directly in the PDF.  

If you realise later on that you made a wrong choice of export format, there are converters, as listed in [this GitHub repository](https://github.com/cneud/ocr-conversion).

In order to guarantee the openness of your project, your data should be **[FAIR](https://www.go-fair.org/fair-principles/)** (Findable, Accessible, Interoperable, Reusable). Simply providing documents with layout information will not be enough, because those would still be missing some content crucial for FAIRness.  

In addition to providing **metadata** for key information about the corpus (title, author(s), sources, etc.), you should provide thorough documentation. First, about the methods and tools used for the transcriptions, preferably open source.  

It is important to document your transcription rules, that is the choices you made so that people can reuse your data in ideal conditions. Reusing transcriptions with different transcription rules only makes the model confused.

There are many reuse options once your data is open. We will only explore two: archiving and sharing your data, and data analysis.  

#### Publish
It ensures that you have a separate, ofen online, backup. It is also a way to share your data, as it could be useful to someone else from the community. You can use repositories like Zenodo, GitHub, or the HTR-United catalogue.  

#### Data Analysis
ATR-ised large corpora can be explored by lexical analysis, text analysis, statistics, etc. Open source tools like TXM or R were developed for this purpose.  

Encoding your text with a standardised markup language, like the Text Encoding Initiative (TEI), allows you to have your corpus ready for publication. There are several open source publication options, like Omeka or TEI Publisher


Sarah Rebecca Ondraszek

Floriane Chiffoleau

Anne Baillot

Mareike König

The most common reason behind an export is to create backups of the data because digital tools and servers are not 100% reliable. Export can be done even with unfinished transcriptions when your project is still considered work in progress.  

In the cases where it is possible to change software, you will want to move your data from the current software to the one you want to migrate to. Similarly, by exporting the transcription, you can feed the data to another tool, which can be one of the reuse options. Exporting can also be done to publish finished transcriptions, whether it is the whole corpus or simply a sample. Finally, if you want to transform your transcribed corpus, an export will be necessary.

Edit actor

Other URLs relevant to the resource, e.g. ORCID, etc.

URL, ideally landing page, of the resource.

Person/group/body who helped create the resource.

Should be concise and raise interest in the entry. Allows <Link>Markdown</Link> content.

Other URLs relevant to the resource, e.g. code, DOI, etc.

Upload media

URL pointing to info about the access policy.

The activities you can do with the resource. See <Link></Link>.

Name of the conference where paper was given.

Describes the discipline covered by resource. See <Link></Link>.

Locations where the Resource is offered. See <Link></Link>.

URL to helpdesk for incidents & user requests.

Audience targeted by the resource. See <Link></Link>.

A particular published issue of a journal.

Concept or term related to MP entry. See <Link></Link>.

Language(s) in which a resource is available. See <Link></Link>.

Select license pertaining to resource. See <Link></Link>. If license is unknown, use the "Terms of use" property field to describe the usage terms.

Status of the Resource life-cycle. See <Link></Link>.

Mode of use for the resource. See <Link></Link>.

File format of the linked resource. See <Link></Link>.

Page #s of a resource, separate by commas.

Refine the resource's nature and function. See <Link></Link>.

Links to non-MP materials that are relevant.

Info about performance levels provider expected to deliver.

Standard used by the resource. See <Link></Link>.

Technology Readiness Level of the Resource. See <Link></Link>.

Resource user manual and documentation URL.

Version of the tool or service that is linked.

The volume of a journal or multivolume book.

Edit source

Name

If you are having trouble with the sign in process, please <ContactLink>contact the SSH Open Marketplace team</ContactLink>.

If you are having trouble with the sign up process, please <ContactLink>contact the SSH Open Marketplace team</ContactLink>.

Making Data Reusable in the Context of Automatic Text Recognition

Media

Related items(1)

Automatic Text Recognition Roadmap

Workflow steps(4)

1 Choose the Right Format

2 Guarantee the Openness of your Project

3 Provide Documentation

4 Publish your Data