Leibniz Transactions on Embedded Systems

ISSN 2199-2002


Volumes

Volume

Leibniz Transactions on Embedded Systems, Volume 9

LITES, Volume 9
Volume

Leibniz Transactions on Embedded Systems, Volume 8

LITES, Volume 8
  • Issue 1 - Special Issue on Embedded Systems for Computer Vision (2022)
  • Issue 2 - Special Issue on Distributed Hybrid Systems (2022)
Volume

Leibniz Transactions on Embedded Systems, Volume 7

LITES, Volume 7
  • Issue 1 - Special Issue on Embedded System Security (2021)
Volume

Leibniz Transactions on Embedded Systems, Volume 6

LITES, Volume 6
Volume

Leibniz Transactions on Embedded Systems, Volume 5

LITES, Volume 5
Volume

Leibniz Transactions on Embedded Systems, Volume 4

LITES, Volume 4
Volume

Leibniz Transactions on Embedded Systems, Volume 3

LITES, Volume 3
Volume

Leibniz Transactions on Embedded Systems, Volume 2

LITES, Volume 2
Volume

Leibniz Transactions on Embedded Systems, Volume 1

LITES, Volume 1

LITES publishes original articles on all aspects of embedded computing systems according to the principles of Open Access. The journal is published by the European Design and Automation Association (EDAA) \ EMbedded Systems Special Interest Group (EMSIG) and Schloss Dagstuhl -- Leibniz-Zentrum für Informatik GmbH, Dagstuhl Publishing

LITES aims at efficient reviewing procedures to ensure that articles are published within one year of submission. LITES is continuously open for submission.


Aims and Scope

Leibniz Transactions on Embedded Systems (LITES) aims to publish high-quality scholarly articles and to ensure efficient submission, reviewing, and publishing procedures that will result in timely publication. All articles are published open access, i.e., are accessible online at no cost to the reader. All rights are retained by the author(s).

LITES publishes original articles on all aspects of embedded computing systems.

The journal is flexible in the types of articles it publishes. The range includes (but is not limited to) regular technical papers, literature surveys, historical perspectives, position papers, tools papers, and companion papers to open-access research artifacts (such as open-source software and hardware designs, data sets, case studies, challenge problems and competitions, etc.). All contributions that advance the state of the art and/or the scientific discourse on embedded computing systems are welcome.

Topics of interest include (but are not limited to):

  • the design, implementation, testing, validation, and verification of embedded software and hardware systems,
  • their temporal and logical correctness,
  • resource efficiency,
  • embedded security,
  • design space exploration and optimization,
  • embedded artificial intelligence (AI),
  • formal foundations of embedded systems,
  • embedded systems in the context of larger cyber-physical systems (CPS) and networked systems, and - specific application domains (e.g., automotive systems, avionics, robotics, healthcare, autonomous systems, etc.).

LITES welcomes all methods of scientific inquiry, including (but not limited to) systems building and empirical evaluation, mathematical modeling and rigorous proof, formal methods, deployment studies and reflections on “lessons learned” in practice, as well as statistical and empirical methods, surveys of industry practice, and user studies.


Open Access Policy
LITES articles are peer-reviewed and published according to the principle of Open Access, i.e., they are available online and free of charge. The authors retain their copyright. Preprints (pre-review manuscripts), post prints (authors accepted manuscripts, AAM), and the version of record (VoR) can be deposited without restrictions.
License
Each article is published under a Creative Commons CC BY license (http://creativecommons.org/licenses/by/4.0/).
The metadata provided by Dagstuhl Publishing on its webpages, as well as their export formats (such as XML or BibTeX) available at our website, is released under the CC0 1.0 Public Domain Dedication license (https://creativecommons.org/publicdomain/zero/1.0/legalcode).

Processing Charge

Schloss Dagstuhl, the publisher of LITES, charges a moderate article-processing charge (APC) of 100€ (net) upon acceptance, which typically is paid by the author or his/her institution. Authors without institutional support or facing financial hardship may apply for an APC waiver.

Schloss Dagstuhl is a publicly funded nonprofit organization. The modest APC serves to offset only the real costs incurred during the publication process and does not generate any profits.

Additionally, the first 20 accepted papers each year automatically receive a FULL APC WAIVER thanks to financial support by EMSIG.


ISSN
2199-2002
Identifier
Each issue is assigned a DOI and a URN.
Each article is assigned a DOI and a URN.
To facilitate author identification, the Open Researcher and Contributor ID (ORCID) is optionally included during upload so that authors can be uniquely linked to their ORCID iD.

Longterm Preservation
LITES is digitally archived in cooperation with the Deutsche Nationalbibliothek/German National Library (http://www.dnb.de).

Publication Ethics
Dagstuhl Publishing as a division of Schloss Dagstuhl – Leibniz-Zentrum für Informatik GmbH (LZI, or Schloss Dagstuhl for short) and its series and journals adhere to CORE practices guidance laid by COPE (Committee on Publication Ethics) and are committed to the rules of good scientific practice in accordance with the guidelines of the Leibniz Association and the German Research Foundation (DFG). We expect all parties (so authors, editors, and reviewers) involved in the publication and review process of contributions to be published in the series to follow these core practises and the guidelines. Allegations of misconduct will be investigated in accordance with the COPE Best Practice Guidelines as far as is practicable. If notified of a potential breach of publication ethics, we encourage editors and authors to inform Dagstuhl Publishing contact as soon as possible. Detailed information can be found on the Publication Ethics website.

Constitution

LITES shall have an editor-in-chief and an editorial board consisting of 10 to 20 associate editors. LITES is operated not-for-profit. All editors and reviewers are unpaid volunteers. The APC is charged to compensate the real costs and can be waived in exceptional circumstances on a case-by-case basis for authors without institutional support and for who the APC would result in undue financial hardship.

Duties of the editorial board
  • The editors shall find competent reviewers for submissions and assign submissions to these reviewers, monitor the reviews respecting the timelines. They shall respect the COPE (Committee on Publication Ethics) Code of Conduct for Journal Editors/Journal Publishers (see http://publicationethics.org).
  • The editors will be supported by a submission management system.
  • The terms for editors last 4 years, renewable once.
Review Policy

Decisions are taken by the associate editor in charge of a submission. A minimum number of 3 reviews for each submissions required. The journal uses a single-anonymous peer-review process (i.e., authors do not know who the reviewers are, but reviewers do know who the authors are).

The editor-in-chief (EiC) assigns each new submission to a responsible associate editor, taking into account possible conflicts of interest (CoI), and has the final responsibility for decisions about acceptance and rejection of submissions.

The associate editors

  • filter out inadequate submissions (out of scope, inappropriate presentation, 'spam'),
  • depending on the case, trigger consultation with the editor-in-chief,
  • select, assign, and invite reviewers,
  • keep track of pending reviews,
  • ensure that reviewers do not have any conflicts of interests,
  • in case of ambiguous reviews
    • trigger clarification among conflicting reviewers, and/or
    • organize additional reviews.

Reviewers provide

  • a detailed review judging the scientic value and relevance of the submitted work according to the criteria set out below,
  • a decision whether an article should be accepted, revised, or rejected,
  • a decision whether the submitted article would need language- and copy-editing in case of acceptance.

Review Criteria

Manuscripts are reviewed based on the following criteria:

  • Novelty — does the paper make a well-argued new contribution to
    • the state of the art in embedded computing systems, broadly construed, and/or
    • to the scientific discourse on the study of embedded computing systems?
  • Validity of conclusions — are all claims made in the paper, either formally or informally, appropriately substantiated by rigorous proof, convincing argument, and/or experimental validation (as appropriate for the paper’s specific contributions)?
  • Technical correctness — are all derivations and methods technically sound?
  • Reproducibility — does the paper present sufficient information (ideally, accompanying research artifacts) for others to reproduce and build on its findings?

Papers are not reviewed on their perceived significance or expected impact, which are ultimately guesswork and best left to history.


Conflicts of Interest

A conflict of interest (CoI) exists between a reviewer or editor and the authors if they:

  • had at any time a supervisor/PhD student relationship,
  • are both from the same institution, or have worked at the same institution in the past 36 months at the time of submission,
  • are currently working together on a research paper, project, or funding proposal, or have done so during the past 36 months at the time of submission,
  • are related, close personal friends, or unable to assess the work objectively (e.g., due to prior conflict), or
  • are in some form of financial relationship, or have been at some point during the past 36 months at the time of submission.

Further information can be found on the Publication Ethics website of Dagstuhl Publishing.


Publication Timeline

The target timelines for handling submissions are:

  • Max. 1 year overall from submission to publication.
  • 6 months in case of reviews recommending Minor Revision.
  • Max. 1 month for reviewer assignment
  • Max. 4 months from reviewer assignment to review.
  • Max. 3 months for author corrections to final version.

Author Guidelines

Authors shall submit original work that is not submitted elsewhere while the submission and review process of LITES is going on. Authors are encouraged to submit software and data along with the article submission. This enables the replication of experiments and helps other researchers to build on the published results.

Extensions of previously published workshop and conference papers are welcome. Extensions of conference papers and workshop papers published with a DOI require at least 30% new material to be accepted. The manuscript should include a statement explaining the novel contributions on top of the preliminary conference or workshop version of the manuscript. When in doubt whether a (planned) extension meets these requirements, please inquire with the editor-in-chief for clarification.

Language

Articles must be written in British or American English. Please be consistent – use the same form of English (i.e., British or American) throughout the text.

Length

A submitted article shall normally be no more than 25 pages (not inclduing abstract and bibliography). Longer papers might be considered but there must be a strong justification. When planning to submit a paper significantly exceeding the 25-page limit, please reach out to the editorin-chief with a justification to obtain prior approval.

Submission

Please submit manuscripts via the LITES submission system. LITES OJS Login / LITES OJS Registration


Templates and Example Files

Please download the current version of the LITES style along with an example file and detailed author instructions:

lites-v2021 v2021.2.2

For older releases and an issue tracker, see our GitHub archive.


Submission Preparation Checklist

As part of the submission process, authors are required to check off their submission's compliance with all of the following guidelines. Submissions not adhering to these guidelines may be returned to the authors without further review.

  • The submission has not been previously published, nor is it before another journal for consideration (or an explanation has been provided in Comments to the Editor).
  • The submission file is in PDF format.
  • Where available, URLs for the references have been provided.
  • If the manuscript is an extension of a previously published workshop or conference paper, the manuscript contains a statement explaining the novel contribution relative to preliminary version already published.

Typesetting instructions - Summary

LITES publishes original articles on all aspects of embedded computing systems according to the principles of Open Access. The journal is published by the European Design and Automation Association (EDAA) \ EMbedded Systems Special Interest Group (EMSIG) and Schloss Dagstuhl -- Leibniz-Zentrum für Informatik GmbH, Dagstuhl Publishing

LITES aims at efficient reviewing procedures to ensure that articles are published within one year of submission. LITES is continuously open for submission.

In order to do justice to the high scientific quality of the journal, which is ensured by the thorough review process, we believe that LITES articles must have an attractive and consistent layout matching the standard of the journal. Moreover, the quality of the metadata, the typesetting and the layout must also meet the requirements of other external parties such as indexing services, DOI registry, funding agencies, among others. The provided guidelines serve as the baseline for the authors, editors, and the publisher to create documents that meet as many different requirements as possible.

Please comply with the following instructions when preparing your article for LITES. (See Instructions for Authors for more details.)


Minimum requirements
  • Use pdflatex and an up-to-date LaTeX system.
  • Use further LaTeX packages and custom made macros carefully and only if required.
  • Use the provided sectioning macros: \section, \subsection, \subsubsection, \paragraph, \paragraph*, and \subparagraph*.
  • Provide suitable graphics of at least 300dpi (preferably in PDF format).
  • Use BibTeX and keep the standard style (\bibstyle{plainurl} ) for the bibliography.
  • Please try to keep the warnings log as small as possible. Avoid overfull \hboxes and any kind of warnings/errors with the referenced BibTeX entries.
  • Use a spellchecker to correct typos.

Mandatory metadata macros

Please set the values of the metadata macros carefully since the information parsed from these macros will be passed to publication servers, catalogues and search engines. Avoid placing macros inside the metadata macros. The following metadata macros/environments are mandatory:

  • \title and, in case of long titles, \titlerunning.
  • \author one for each author, even if two or more authors have the same affiliation.
  • \authorrunning (abbreviated first names) and \Copyright (concatenated full author names)
  • \ccsdesc (ACM 2012 subject classification)
  • \keywords (a comma-separated list of keywords).
  • \relatedversion (if there is a related version, typically the "full version"); please make sure to provide a persistent URL, e.g., at arXiv.
  • \begin{abstract}...\end{abstract}.

Please do not ...

Generally speaking, please do not override the style defaults concerning spacing, font and color settings. To be more specific, a short checklist also used by Dagstuhl Publishing during the final typesetting is given below. In case of non-compliance with these rules, Dagstuhl Publishing will remove the corresponding parts of LaTeX code and replace it with the defaults. In serious cases, we may reject the LaTeX-source and expect the corresponding author to revise the relevant parts.

  • Do not use a different main font. (For example, the times package is forbidden.)
  • Do not alter the spacing of the provided style file.
  • Do not use enumitem and paralist. (The enumerate package is preloaded, so you can use \begin{enumerate}[(a)] or the like.)
  • Do not use "self-made" sectioning commands (e.g., \noindent{\bf My Paragraph}).
  • Do not hide large text blocks using comments or \iffalse ... \fi constructions.
  • Do not use conditional structures to include/exclude content. Instead, please provide only the content that should be published - in one file - and nothing else.
  • Do not wrap figures and tables with text. In particular, the package wrapfig is not supported.
  • Do not change the bibliography style. In particular, do not use author-year citations. (The natbib package is not supported.)

This is only a summary containing the most relevant details. Please read the complete Instructions for Authors for all details and don't hesitate to contact Dagstuhl Publishing (publishing@dagstuhl.de) in case of questions or comments.


FAQ
Submission

In order to satisfy the standards of our series, please note that we expect an affiliation at least to contain a city and country (for locations in the United States also the state), so we usually don't support requests asking for removing this kind of information from an affiliation.

For organizations with multiple locations please choose the location where you have been most of the time physically when carrying out this work.

We hope that our completion of affiliations according to the above criteria facilitates the contacting of authors as well as the assignment of a work to individual locations, and - last but not least - serves the harmonization of affiliations across the entire volume.

An authorized user is any person (not necessarily an author) that has the permission to edit the paper. (Mostly, the list of authorized users is similar to the list of corresponding authors.) Please note:
  • Authorized users only appear within the Submission Server as far as the processing of the paper (submission, approval) is concerned.
  • They won't appear in the metadata of the published article! (The metadata will be read from the submitted LaTeX code instead.)
  • Authorized users marked with the symbol are already registered to the system. Users without this symbol have been invited to the system but have not created a user account yet.
  • Given the above, it is not necessary to synchronize name and email of authorized users in any way with the data of actual authors. (They rather synchronize automatically with the user accounts on the Submission Server).

At the beginning of the submission process, the submission system has only limited information about the actual authors of the article. But on each upload, the metadata of the paper (including authors) are updated. Before the publication, the authorized users are asked to confirm (or revise, if necessary) the metadata. In more detail:

  • Before the first successful upload of the LaTeX sources of an article, the list of authors shows the authorized users or corresponding authors (if available).
  • After each upload, the list of authors is temporarily extracted from the LaTeX sources. Since this automatic extraction could fail or be faulty, the final authors' information is only extracted by the Dagstuhl Publishing Team during the final typesetting and imported before Author Approval. During Author Approval, you can request corrections on these data.
  • Finally (usually 3 weeks before the publication), the authors are explicitly asked to approve the extracted metadata. At this stage, minor modifications or necessary corrections are still possible.

  • No LaTeX source submitted yet? Don't worry about any errors here. Every time you upload a LaTeX source, the list will automatically be updated according to the \author macros in your file.
  • Otherwise: Simply correct the \author macros in your LaTeX file and do a re-upload. If the error persists, please make sure that the \author macros are contained in the top level of your main LaTeX file (outside \if conditionals) and contain plain data (i.e. preferably no self-defined macros).
  • Note: In any case, Dagstuhl Publishing asks you to confirm/correct the metadata before the work is officially published.

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

  • The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
  • Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
  • It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
  • Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
  • Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
  • Submitting a bbl-file only or an inline-bibliography is not sufficient.

Please note that in the metadata form there are funding fields at the bottom of each author block as well as a general funding field at the very bottom of the form (see "Additional Metadata").

In the PDF, all of these funding fields are merged to one funding block on the title page, where the author-specific funding fields are automatically preceded by the author's name.

Important! Please do not double funding information by repeating in the general field what is already contained in the author specific ones and vice versa.

As general rule of how to distribute funding information on the different fields consider the following: If a funding is clearly assigned to an author, please use the author-specific funding block. You should only deviate from this rule if the funding block on the title page of the PDF becomes unnecessarily long due to the fact that several authors have the same funding information.

Note that there is an automatic extraction of (most of the) metadata on every upload. On editing these metadata you have to distinguish two cases:
  • The values of the grey (disabled) input fields can only be modified by editing the LaTeX source code and performing a re-upload of the paper afterwards.
  • For your convenience, the values of the white input fields (if any) can be edited directly in the corresponding web-form (no re-upload needed). We will process these changes later during the final typesetting.

Since the automatic extraction could fail or be faulty, the final version of metadata will be extracted by the Dagstuhl Publishing Team after the typesetting is done.

In any case we ask you to confirm/correct the metadata before the work is officially published!

\relatedversion{...} may be used to denote a related version like a full version, extended version, or also a predecessor usually published in a reliable repository like arXiv or HAL.

As all metadata should be self-contained, please add a persistent URL, e.g. \relatedversion{A full version of the paper is available at \url{...}.}. This also simplifies the access for all readers. Additional to the URL, you might add a reference (\cite{...}).

Metadata should be self-contained as they are not only part of the document / PDF but also extracted and stored in a machine-readable format along with the actual document.

Please note: As hosting on a (personal or university) webpage or in cloud storage is not really sufficient for durable / persistent file storage, we highly recommend to publish your document in a reliable repository like arXiv or HAL.

Please note that a subject classification contained in your LaTeX file may be considered invalid if we cannot literally match an entry from the 2012 ACM Computing Classification System in a \ccsdesc{...} macro in your LaTeX file. (That can have many causes.)

To save you the trouble of a new upload, please find the "Search ACM Classifications"-input field in the upload form. There you can search for the corresponding valid classification. (By using the last part of the intended classification as a search term one usually ends up with a good pre-selection.)

Note that invalid classifications will automatically be removed from the LaTeX code during the final typesetting by Dagstuhl Publishing.

Author Approval

  • During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
  • authors approve or ask for (minor) corrections
  • Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
  • Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
  • Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
  • Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).

If you click on "Save and Finish Author Approval", we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata (if necessary) AND in the LaTeX file.

In any case, even if we cannot make the requested changes, you will be informed by E-mail.


IMPORTANT! Please note that only minor corrections should be done at this stage. Here, "minor" also refers to the total number of changes. (We have already had inquiries with 50 change requests, most of them typos. Although each request is minor, the implementation is time-consuming in sum.) Requests that exceed our processing capacities and thus endanger the timely publication of the whole volume may be rejected.

As soon as some authorized user (usually you or your co-authors, if any) finishes the approval request and submits it to Dagstuhl Publishing (this happens at the end of Step 2), we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata AND in the LaTeX file.


Note that, when submitting the approval, you can decide on if you want to see the changed document again or if you consider the document as approved after the changes have been made (without a further preview).


In any case, even if we cannot make the requested changes, you will be informed by E-mail.

Publication Workflow

  • During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
  • authors approve or ask for (minor) corrections
  • Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
  • Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
  • Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
  • Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).
LaTeX Style

Here is an example of a completely filled author macro:

\author{John Q. Public}
{Institute of Pure Nonsense, Dummy University, Atlantis
 \and \url{http://www.myhomepage.edu}}
{johnqpublic@dummyuni.org}
{https://orcid.org/0000-0002-1825-0097}
{funded by the man in the moon.}

Please note:

  • Use full first and last name.
  • City and country belong to the minimum requirements on an affiliation.
  • If an author has several different affiliations, please clearly separate them with the keyword \and.
  • E-mail, ORCID, and funding are optional.
  • Author macros cannot be shared! Please use separate author macros even if two or more authors have the same affiliation!

This macro sets the page header of odd pages, which is an abbreviated version of the concatenated author string. Sample usage:

\authorrunning{J.\,Q. Public, A.\,E. Access, and E. Example}

Please...

  • abbreviate first names
  • in case of middle initials: use \, as illustrated in the example
  • be consistent with the \author macros
  • in case of 2 authors: concatenate with " and "
  • in case of 3 or more authors, see the sample for concatenation
  • in case of overfull \hboxes: use the name of the first author and "et al."

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

  • The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
  • Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
  • It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
  • Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
  • Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
  • Submitting a bbl-file only or an inline-bibliography is not sufficient.

\ccsdesc{...} is for classification information following the ACM 2012 Computing Classification System. Sample usage:

\ccsdesc{Theory of computation~Proof complexity}
\ccsdesc{Theory of computation~Quantum complexity theory}

Please feel free to use our ACM 2012 Subject Finder to search for appropriate classifications and to generate the necessary LaTeX code.

Using this macro, you specify the copyright holder (appearing at the bottom of the title page) which is usually the team of authors. Sample usage:

\Copyright{John Q. Public, Adam E. Access, and Eve Example}

Please...

  • use full first and last names
  • be consistent with the \author macros
  • in case of 2 authors: concatenate with " and "
  • in case of 3 or more authors, see the sample for concatenation

This macro should be used to capture general (i.e. not author-specific) funding information.

If a funding can be clearly assigned to an author, please use the last part of the \author macro instead.

Sample usage:

\keywords{Theory of Everything, indefinite Metrics, abstract Nonsense}

Please note:

  • comma as delimiter
  • first word and every proper noun should be capitalized

\relatedversiondetails{...} may be used to denote a related version like a full version, extended version, or also a predecessor usually published in a reliable repository like arXiv or HAL. Sample usage:

\relatedversiondetails[cite={bibtex-reference}]{Full Version}{https://arxiv.org/abs/...}

As all metadata should be self-contained, please add a persistent URL to the cited version (as illustrated above). This also simplifies the access for all readers.

\supplementdetails{...} may be used to denote supplements like related research data, source code, posters, slides, ... hosted on a repository like zenodo, figshare, ..., Software Heritage.

Sample usage:

\supplementdetails[subcategory={Source Code}]{Software}{https://github.com/...}

The subcategory is free text, while the category (Software in the above example) must be one of the following words: Audiovisual, Collection, DataPaper, Dataset, Event, Image, InteractiveResource, Model, PhysicalObject, Service, Software, Sound, Text, Workflow, Other. (This is controlled vocabulary prescribed by our DOI provider.)

Please note: As hosting on a (personal or university) webpage or in cloud storage is not really sufficient for durable/persistent file storage, we highly recommend to publish your document in a reliable repository.


Not found?

Didn't find what you are looking for? Don't hesitate to leave us message at publishing@dagstuhl.de!

Front Matter Template and Example Files

Please download the current version of the LITES front matter style along with an example file:

litesmaster-v2021 v2021.2.2

Editor Login

Submissions via LITES Submission System: LITES OJS Login / LITES OJS Registration


FAQ
Submission

In order to satisfy the standards of our series, please note that we expect an affiliation at least to contain a city and country (for locations in the United States also the state), so we usually don't support requests asking for removing this kind of information from an affiliation.

For organizations with multiple locations please choose the location where you have been most of the time physically when carrying out this work.

We hope that our completion of affiliations according to the above criteria facilitates the contacting of authors as well as the assignment of a work to individual locations, and - last but not least - serves the harmonization of affiliations across the entire volume.

An authorized user is any person (not necessarily an author) that has the permission to edit the paper. (Mostly, the list of authorized users is similar to the list of corresponding authors.) Please note:
  • Authorized users only appear within the Submission Server as far as the processing of the paper (submission, approval) is concerned.
  • They won't appear in the metadata of the published article! (The metadata will be read from the submitted LaTeX code instead.)
  • Authorized users marked with the symbol are already registered to the system. Users without this symbol have been invited to the system but have not created a user account yet.
  • Given the above, it is not necessary to synchronize name and email of authorized users in any way with the data of actual authors. (They rather synchronize automatically with the user accounts on the Submission Server).

At the beginning of the submission process, the submission system has only limited information about the actual authors of the article. But on each upload, the metadata of the paper (including authors) are updated. Before the publication, the authorized users are asked to confirm (or revise, if necessary) the metadata. In more detail:

  • Before the first successful upload of the LaTeX sources of an article, the list of authors shows the authorized users or corresponding authors (if available).
  • After each upload, the list of authors is temporarily extracted from the LaTeX sources. Since this automatic extraction could fail or be faulty, the final authors' information is only extracted by the Dagstuhl Publishing Team during the final typesetting and imported before Author Approval. During Author Approval, you can request corrections on these data.
  • Finally (usually 3 weeks before the publication), the authors are explicitly asked to approve the extracted metadata. At this stage, minor modifications or necessary corrections are still possible.

  • No LaTeX source submitted yet? Don't worry about any errors here. Every time you upload a LaTeX source, the list will automatically be updated according to the \author macros in your file.
  • Otherwise: Simply correct the \author macros in your LaTeX file and do a re-upload. If the error persists, please make sure that the \author macros are contained in the top level of your main LaTeX file (outside \if conditionals) and contain plain data (i.e. preferably no self-defined macros).
  • Note: In any case, Dagstuhl Publishing asks you to confirm/correct the metadata before the work is officially published.

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

  • The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
  • Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
  • It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
  • Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
  • Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
  • Submitting a bbl-file only or an inline-bibliography is not sufficient.

Note that there is an automatic extraction of (most of the) metadata on every upload. On editing these metadata you have to distinguish two cases:
  • The values of the grey (disabled) input fields can only be modified by editing the LaTeX source code and performing a re-upload of the paper afterwards.
  • For your convenience, the values of the white input fields (if any) can be edited directly in the corresponding web-form (no re-upload needed). We will process these changes later during the final typesetting.

Since the automatic extraction could fail or be faulty, the final version of metadata will be extracted by the Dagstuhl Publishing Team after the typesetting is done.

In any case we ask you to confirm/correct the metadata before the work is officially published!

\relatedversion{...} may be used to denote a related version like a full version, extended version, or also a predecessor usually published in a reliable repository like arXiv or HAL.

As all metadata should be self-contained, please add a persistent URL, e.g. \relatedversion{A full version of the paper is available at \url{...}.}. This also simplifies the access for all readers. Additional to the URL, you might add a reference (\cite{...}).

Metadata should be self-contained as they are not only part of the document / PDF but also extracted and stored in a machine-readable format along with the actual document.

Please note: As hosting on a (personal or university) webpage or in cloud storage is not really sufficient for durable / persistent file storage, we highly recommend to publish your document in a reliable repository like arXiv or HAL.

Please note that a subject classification contained in your LaTeX file may be considered invalid if we cannot literally match an entry from the 2012 ACM Computing Classification System in a \ccsdesc{...} macro in your LaTeX file. (That can have many causes.)

To save you the trouble of a new upload, please find the "Search ACM Classifications"-input field in the upload form. There you can search for the corresponding valid classification. (By using the last part of the intended classification as a search term one usually ends up with a good pre-selection.)

Note that invalid classifications will automatically be removed from the LaTeX code during the final typesetting by Dagstuhl Publishing.

Author Approval

  • During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
  • authors approve or ask for (minor) corrections
  • Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
  • Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
  • Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
  • Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).

If you click on "Save and Finish Author Approval", we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata (if necessary) AND in the LaTeX file.

In any case, even if we cannot make the requested changes, you will be informed by E-mail.


IMPORTANT! Please note that only minor corrections should be done at this stage. Here, "minor" also refers to the total number of changes. (We have already had inquiries with 50 change requests, most of them typos. Although each request is minor, the implementation is time-consuming in sum.) Requests that exceed our processing capacities and thus endanger the timely publication of the whole volume may be rejected.

As soon as some authorized user (usually you or your co-authors, if any) finishes the approval request and submits it to Dagstuhl Publishing (this happens at the end of Step 2), we are notified about your request.

Then we check if the proposed changes can be implemented. (Do they comply with the standards of the series? Are there no consistency issues? Are there no technical limitations, e.g. charset problems, ...).

In case these checks are positive, we implement the changes both in the metadata AND in the LaTeX file.


Note that, when submitting the approval, you can decide on if you want to see the changed document again or if you consider the document as approved after the changes have been made (without a further preview).


In any case, even if we cannot make the requested changes, you will be informed by E-mail.

Publication Workflow

  • During this period (of usually 3 working days) authors are shown a pdf preview of their paper along with the extracted metadata.
  • authors approve or ask for (minor) corrections
  • Dagstuhl Publishing asks authors to help with resolving issues detected during the final typesetting (if any)
  • Dagstuhl Publishing checks the correction requests and revises the papers (if possible)
  • Authors are informed at an early stage on the dates and can authorize other persons to do the approval on behalf of them (if necessary).
  • Editors are not involved in this process, but can see the revisions in a change-log (during the editor approval step).

Before the volume is officially published, Dagstuhl Publishing...
  • creates a web-portal on the Dagstuhl Publication Server DROPS and communicates the link to the editors
  • provides a detailed change-log for all papers
  • asks the editors to resolve open issues that could not be clarified during the author approval (if any)
  • waits for an explicit approval of the editors to expose the web-portal to the public

The editors check everything carefully and ask for minor changes, if necessary.

When approved, the volume will be officially published.

First note that there are no automatic actions triggered when the editor submission deadline has passed! You actually decide on when to hand over the volume to Dagstuhl Publishing. (However, if you miss the deadline, we cannot guarantee a timely publication.)

Your tasks here are:

  • checking for completeness and remind delayed authors on submitting their papers
  • checking the order of papers (re-ordering, if necessary)
  • checking for/setting the correct paper categories (e.g. Invited Talk, Extended Abstract, ...)
  • writing a preface and including it into the pre-generated front matter provided by the Submission System
  • handing over the volume at the specified date (editor submission deadline) to Dagstuhl Publishing
  • no need to edit LaTeX sources submitted by the authors manually (although the possibility is given)

First note that the specified author submission deadline does not automatically trigger any actions (like closing the submission). However, it is the deadline communicated to the authors in E-mails generated by the system. Actually, you decide on when to close the submission manually.

The editor's tasks during paper submission are:

  • editors monitor the progress of paper submissions (there is an E-mail notification)
  • editors send reminders (guided by the Submission Server) in case of incomplete submissions
  • editors check the page limits (if any) and encourage the authors to comply with the style guidelines
  • editors write a preface and include it in a pre-generated front matter template
  • editors guarantee a handing over of the volume within the agreed deadline
  • no need to check the submitted LaTeX sources manually (there are some automatic checks on upload)
  • no need to do any kind of typesetting
LaTeX Style

This macro sets the page header of odd pages, which is an abbreviated version of the concatenated author string. Sample usage:

\authorrunning{J.\,Q. Public, A.\,E. Access, and E. Example}

Please...

  • abbreviate first names
  • in case of middle initials: use \, as illustrated in the example
  • be consistent with the \author macros
  • in case of 2 authors: concatenate with " and "
  • in case of 3 or more authors, see the sample for concatenation
  • in case of overfull \hboxes: use the name of the first author and "et al."

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

  • The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
  • Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
  • It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
  • Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
  • Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
  • Submitting a bbl-file only or an inline-bibliography is not sufficient.

\ccsdesc{...} is for classification information following the ACM 2012 Computing Classification System. Sample usage:

\ccsdesc{Theory of computation~Proof complexity}
\ccsdesc{Theory of computation~Quantum complexity theory}

Please feel free to use our ACM 2012 Subject Finder to search for appropriate classifications and to generate the necessary LaTeX code.

Using this macro, you specify the copyright holder (appearing at the bottom of the title page) which is usually the team of authors. Sample usage:

\Copyright{John Q. Public, Adam E. Access, and Eve Example}

Please...

  • use full first and last names
  • be consistent with the \author macros
  • in case of 2 authors: concatenate with " and "
  • in case of 3 or more authors, see the sample for concatenation

This macro should be used to capture general (i.e. not author-specific) funding information.

If a funding can be clearly assigned to an author, please use the last part of the \author macro instead.

Sample usage:

\keywords{Theory of Everything, indefinite Metrics, abstract Nonsense}

Please note:

  • comma as delimiter
  • first word and every proper noun should be capitalized

\relatedversiondetails{...} may be used to denote a related version like a full version, extended version, or also a predecessor usually published in a reliable repository like arXiv or HAL. Sample usage:

\relatedversiondetails[cite={bibtex-reference}]{Full Version}{https://arxiv.org/abs/...}

As all metadata should be self-contained, please add a persistent URL to the cited version (as illustrated above). This also simplifies the access for all readers.

\supplementdetails{...} may be used to denote supplements like related research data, source code, posters, slides, ... hosted on a repository like zenodo, figshare, ..., Software Heritage.

Sample usage:

\supplementdetails[subcategory={Source Code}]{Software}{https://github.com/...}

The subcategory is free text, while the category (Software in the above example) must be one of the following words: Audiovisual, Collection, DataPaper, Dataset, Event, Image, InteractiveResource, Model, PhysicalObject, Service, Software, Sound, Text, Workflow, Other. (This is controlled vocabulary prescribed by our DOI provider.)

Please note: As hosting on a (personal or university) webpage or in cloud storage is not really sufficient for durable/persistent file storage, we highly recommend to publish your document in a reliable repository.


Not found?

Didn't find what you are looking for? Don't hesitate to leave us message at publishing@dagstuhl.de!

Contact Dagstuhl Publishing
Dagstuhl Publishing Team
In which format should the bibliography be submitted?

Dagstuhl Publishing uses BibTEX to format references. Thereby the BibTEX style plainurl is used for BibTEX processing (\bibliographystyle{plainurl}).

  • The bibliographical entries should be complete according to BibTEX standards, (no warnings or errors should occur).
  • Whenever possible, references should contain an external link, e.g., DOI (preferred) or URL
  • It is highly recommended to use dblp to enrich the references and, e.g., add missing DOIs.
  • Please do not change the bibliographic style! Author-year citations are not allowed. (So the natbib package is not supported by the current styles of Dagstuhl Publishing.)
  • Unreferenced bibliography entries will be removed, \nocite{*} is forbidden.
  • Submitting a bbl-file only or an inline-bibliography is not sufficient.
How to use the \author macro?

Here is an example of a completely filled author macro:

\author{John Q. Public}
{Institute of Pure Nonsense, Dummy University, Atlantis
 \and \url{http://www.myhomepage.edu}}
{johnqpublic@dummyuni.org}
{https://orcid.org/0000-0002-1825-0097}
{funded by the man in the moon.}

Please note:

  • Use full first and last name.
  • City and country belong to the minimum requirements on an affiliation.
  • The ORCID field is mandatory. Include ORCID identifiers for each author. In case you don't have an ORCID yet, please request one on the ORCID website. Please contact your co-authors directly for their ORCID and only use ORCIDs verified by them.
  • If an author has several different affiliations, please clearly separate them with the keyword \and.
  • E-mail and funding are optional.
  • Author macros cannot be shared! Please use separate author macros even if two or more authors have the same affiliation!
How to use the \authorrunning macro?

This macro sets the page header of odd pages, which is an abbreviated version of the concatenated author string. Sample usage:

\authorrunning{J.\,Q. Public, A.\,E. Access, and E. Example}

Please...

  • abbreviate first names
  • in case of middle initials: use \, as illustrated in the example
  • be consistent with the \author macros
  • in case of 2 authors: concatenate with " and "
  • in case of 3 or more authors, see the sample for concatenation
  • in case of overfull \hboxes: use the name of the first author and "et al."
How to use the \Copyright macro?

Using this macro, you specify the copyright holder (appearing at the bottom of the title page) which is usually the team of authors. Sample usage:

\Copyright{John Q. Public, Adam E. Access, and Eve Example}

Please...

  • use full first and last names
  • be consistent with the \author macros
  • in case of 2 authors: concatenate with " and "
  • in case of 3 or more authors, see the sample for concatenation
How to use the \ccsdesc macro?

\ccsdesc{...} is for classification information following the ACM 2012 Computing Classification System. Sample usage:

\ccsdesc{Theory of computation~Proof complexity}
\ccsdesc{Theory of computation~Quantum complexity theory}

Please feel free to use our ACM 2012 Subject Finder to search for appropriate classifications and to generate the necessary LaTeX code.

How to use the \keywords macro?

Sample usage:

\keywords{Theory of Everything, indefinite Metrics, abstract Nonsense}

Please note:

  • comma as delimiter
  • first word and every proper noun should be capitalized
How to use the \relatedversiondetails macro?

\relatedversiondetails{...} may be used to denote a related version like a full version, extended version, or also a predecessor usually published in a reliable repository like arXiv or HAL. Sample usage:

\relatedversiondetails[cite={bibtex-reference}]{Full Version}{https://arxiv.org/abs/...}

As all metadata should be self-contained, please add a persistent URL to the cited version (as illustrated above). This also simplifies the access for all readers.

Questions / Remarks / Feedback
X

Feedback for Dagstuhl Publishing


Thanks for your feedback!

Feedback submitted

Could not send message

Please try again later or send an E-mail