Transactions on Graph Data and Knowledge

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.

• 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.

The metadata associated with a DOI may not be available in all services, especially in the context of Crossref. The reason for this is that we use DataCite as our DOI registry and not CrossRef. CrossRef is certainly the largest registry for DOIs, but there are a few others (see https://www.doi.org/the-community/existing-registration-agencies/).

However, our data can be retrieved in a number of ways. DataCite offers several search options and APIs that are similar to those of CrossRef, see for example https://commons.datacite.org/.

Alternatively, you can of course retrieve the complete set of metada directly from us (https://drops.dagstuhl.de/metadata) or the basic data set from dblp (https://dblp.org).

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.

The left justification of the equations is not random but part of the LIPIcs style and the other styles of Dagstuhl Publishing. We decided some years ago that we prefer text-like content (incl. equations and captions) to be left-justified and not centered. In contrast, figures and tables are centered. See also the LIPIcs Author Guidelines:

https://submission.dagstuhl.de/styles/instructions/lipics

The alignment of the equations is thus a deliberate style decision of the series. Therefore, we cannot comply with any request for centering.

• 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!

We try to harmonize dashes across the whole volume (even across the whole series). We clearly address this as one of our typesetting actions in the author guidelines - admittedly, at the very end, cf. p.1:21, Section 3.2 of our current author instructions for LIPIcs authors.

However, seeking uniformity is always difficult if different style guides give different advice.

The University of Oxford Style Guide explicitly says on p. 13:

m-dash
Do not use; use an n-dash instead.

n-dash
Use in a pair in place of round brackets or commas, surrounded by spaces.
Use singly and surrounded by spaces to link two parts of a sentence, in place of a colon.

Generally, it seems that in British English the " -- " variant is preferred over "---", whereas in American English it is just the opposite. (It seems, however, that there is no uniform opinion on this in either language area.)

Hence our replacement ("---" -> " -- ") follows at least one of the accepted style guides.

\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.

Reproducibility is a key aspect of scientific research. In the case of Research and Resources articles, we ask that all resources relevant to the article under submission to TGDK be made available for review and appropriately documented. Aside from improving reproducibility, making resources available has the additional benefits of allowing the community to build upon these resources in their own research, and allowing readers to verify or better understand additional details not mentioned in the article. In case one or more resource cannot be published, we require that the authors explicitly declare this, and justify why.

TGDK requires Research and Resources articles to include a Supplementary Material Statement following a standard format as described below. The purpose of this statement is to allow readers of any such TGDK article to quickly understand what resources have been made available (if any), under what conditions, and where they can be found; otherwise, it should provide readers with a clear justification for relevant resources that cannot be published. The Supplementary Material Statement will also be used by reviewers to assess the Reproducibility/Resource quality criteria for Research/Resource articles. This statement must thus be included with submissions for review (as of December 1, 2024) and in the camera-ready version of relevant articles. This statement is optional for Surveys and other submission types (but highly encouraged when relevant resources are involved).

Supplementary materials are all kinds of resources related to a scholarly article such as research data, source code, research software, posters, slides, ... hosted on a repository like zenodo, figshare, ..., Software Heritage.

Resources should be published in such a way that enables long-term availability via persistent links; for example, use of archival platforms such as arXiv, Figshare, Zenodo, etc. is encouraged. Established platforms such as Github are also acceptable for source code and other materials. We discourage the use platforms not intended for long-term publication, such as a personal homepage, file-sharing services (DropBox, Google Drive), etc. Company, personal and (non-archival) institutional platforms are also not suitable for archival purposes, but they can be used to host live demonstrations and services when accompanied by source code, data, and/or long-term archiving of a static snapshot.

If the article involves no such supplementary resource, the statement is still required with the following declaration: \supplement{The authors declare that this article involves no relevant supplementary resources.}. Such a declaration is typically only applicable for Research articles with full proofs included in the article to substantiate theoretical claims. Such a declaration is never applicable for Resource articles and rarely (if ever) applicable for Research articles with empirical results.

In case there is any relevant supplementary material that cannot be published (e.g., for commercial, ethical, legal, or technical reasons), it must still be discussed in the statement, and a justification must be provided for not publishing it, stating any conditions under which such material could be made (partially) available, if any.

You may wonder why algorithms appear as vector graphics in the HTML version of many documents instead of being an integral part of the HTML output. The reason is the following:

Algorithms combine graphics-like output and text in a way that an accurate HTML-conversion is difficult to obtain in the general case. In particular, we observed major layout issues regarding nested structures (e.g., loops, conditionals, ...) and noticed that the line numbers of the LaTeXML output often do not match the line numbers in the PDF (an inaccuracy which we consider not acceptable).

Whenever necessary by the above reasons, we prefer to embed algorithms as vector graphics (more precisely, as SVG) to guarantee in particular that line breaks and line numbering are consistent between the two document versions (PDF/HTML).

Our LaTeX-to-HTML conversion is based on the open-source tool LaTeXML, as is the case with arXiv.

Since not all LaTeX packages are supported by LaTeXML and many authors use custom macros or LaTeX hacks, it may frequently happen that the direct LaTeXML output contains unacceptable display errors. In severe cases, HTML generation fails completely.

As arXiv also points out, the quality of the HTML output depends largely on best practices in LaTeX use (see arXiv: Submit LaTeX Best Practices).

We collect suggestions for authors on how to create LaTeX that is as suitable as possible for HTML generation in the following FAQ:

• How can authors improve the HTML output of their publications?

Based on feedback from authors, we document the most common problems there and try to gradually expand coverage.

In order to improve the resulting HTML and increase coverage, and to meet our high quality standards as well as those of our authors and readers, Dagstuhl Publishing - unlike arXiv - relies on a semi-automatic transformation process: First, we attempt to resolve incompatibilities manually (at the LaTeX level) in order to enable or improve the conversion. Subsequently, a visual check is performed to identify and correct remaining inconsistencies. This significant additional effort is very promising but also cost-intensive.

Of the over 1000 documents processed so far, 90% have been successfully converted into HTML suitable for publication. However, the significant additional costs are currently not covered by the APC, which already barely covers costs. HTML conversion is therefore currently being run as an experimental project. Only after a thorough evaluation of the project after a minimum period of one year, a decision will be made on whether to continue HTML support.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

PDF remains the primary output format at Dagstuhl Publishing. However, starting in 2025, we will also offer HTML, as HTML content is significantly more accessible on screen readers, screen magnifiers, and mobile devices. While PDFs were developed primarily for true-to-print display, HTML allows for flexible adaptation to users with different needs (e.g. enlarged text, high-contrast display or linear reading aloud by screen readers).

By providing HTML, we want to break down barriers and improve access to our publications.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

HTML (or XML) currently offers the most reliable way to make document content accessible:

• Support from assistive technologies: Screen readers and magnification software can interpret HTML content much better than PDF.
• Structured presentation: HTML allows clear semantic markup (headings, lists, tables, formulas), which is crucial for barrier-free use.
• Flexible use: Content adapts to different devices and screen sizes – a clear advantage for mobile use.

ArXiv also refers to HTML as the most promising way to make scientific content accessible (see arXiv HTML as an accessible format for papers).

See also the related FAQ "Why are we not (yet) using PDF/UA as an accessible format?"

The quality of the HTML output depends heavily on how consistent and standard-compliant a LaTeX document is structured. Some packages or self-defined macros can make conversion difficult or impossible. The following tips are based on arXiv's best practices:

1. Use standard LaTeX
   • Use the document classes and packages Dagstuhl Publishing provides whenever possible.
   • Avoid unnecessary LaTeX hacks or workarounds that are not documented.
2. Maintain semantic structure
   • Mark headings with \section, \subsection, etc. – not just with manual formatting (\textbf, \large).
   • Do not set numbering manually, but use the designated LaTeX commands (enumerate environments).
3. Set mathematical expressions and formulas correctly
   • Always write mathematical expressions in $...$ (inline) or \[...\] / equation environments.
   • Define your own macros sparingly and comprehensibly.
4. Mark tables and figures appropriately
   • Create tables with the tabular environment and, if possible, without exotic extensions.
   • For figures, use \includegraphics in a figure environment and – if possible – add \caption.
   • Specify alt text for figures: \includegraphics[alt={plain-text description of image}]{example-image-a}
5. Avoid incompatible packages
   • Some packages that deeply interfere with the layout (e.g. certain table or math packages) are problematic with LaTeXML.
   • If possible, don’t use additional packages or switch to generally supported packages.
   • See FAQ: Which packages cause problems with LaTeXML?

In short: The cleaner the structure of a LaTeX document, the more likely it is that the HTML conversion will be successful and of high quality.

There are various reasons why an HTML version of a document may not have been published (yet).

If the article (the PDF) was published only recently (up to 3 months ago), it is very likely that HTML production for the volume has not been completed. Once the HTML version has been published, all authors will be informed accordingly.

If your article (the PDF) was published after 1 January 2025 (and not within the last 3 months), the conversion of the article to HTML was probably unsuccessful. There may be various reasons for this. Please read the FAQs for more information:

• How can authors improve the HTML output of their publications?
• Which packages cause problems for LaTeXML?

Of course, you can also contact the publisher at any time.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

PDF/UA (Universal Accessibility) is the ISO standard for accessible PDF documents. Since 2021, our publications have been published in PDF/A (Archivable) format, which is optimised for long-term archiving. In theory, it is possible to create a document that is both PDF/A and PDF/UA compliant. In practice, however, this is currently hardly feasible with LaTeX, as the necessary tools and workflows are not yet mature.

The current status of the LaTeX project for creating Tagged PDF (the basis for PDF/UA) is still experimental (see LaTeX tagging project). A stable version does not yet exist. Before widespread use, extensive compatibility tests would also have to be carried out with the numerous LaTeX packages that our authors use in addition to the classes provided.

We evaluate developments regularly, but currently see no practical way of reliably generating PDF/UA with our LaTeX-based publication process.

LaTeXML already supports a large number of LaTeX packages, but not all of them. Please see this website for the list of packages currently supported by LaTeXML. As a general rule:

• All packages included in the document classes/styles offered by Dagstuhl Publishing are currently compatible with LaTeXML and are supported.
• Problems may arise if authors include additional packages that are not (yet) covered by LaTeXML.

In such cases, we recommend:

1. Checking whether the package is really necessary or whether there is an alternative that is already supported.
2. Contribute to the community: LaTeXML is public domain software and open to contributions from third parties.
   • Open issues and problems can be reported directly in the LaTeXML issue tracker on GitHub.
   • Information on collaboration can be found on the following websites: LaTeXML documentation, Porting LaTeX packages for LaTeXML, and How to Contribute.

In short: All packages provided by Dagstuhl Publishing as standard are safe. For additional packages, authors themselves or together with the LaTeXML community can contribute to improving support.

Here we collect packages that are currently incompatible, along with possible alternatives and workarounds:

• apxproof: Causes LaTeXml to fail. - Do not use, if possible. In particular, remove the package if no appendix is given. If it is only rarely used, try to move the proofs manually to the appendix.
• Proof-at-the-end: same as apxproof.
• kotex: Causes LaTeXml to fail. – Do not use unless strictly necessary.
• siunitx: Not supported by LaTeXml, leaves error messages in the produced HTML. – Do not use unless strictly necessary.
• derivative: Not supported by LaTeXml, leaves error messages in the produced HTML. – Try to use \frac and \partial instead, like \frac{\partial f}{\partial t}
• forest: Not supported by LaTeXml, can be externalized (see note below).
• kbordermatrix: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• mathpartir (inferrules): Not supported by LaTeXml, leaves error messages in the produced HTML. In very simple cases, use ordinary fractions instead. – externalization possible (see note below).
• minted: Try to avoid mintinline if possible unless strictly necessary. If you use it, try to avoid unicode symbols.
• nicematrix: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• prooftree: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• syntax: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• xy: Not supported by LaTeXml, leaves error messages in the produced HTML. - can be externalized (see note below).
• knowledge: Collect knowledge definitions in the LaTeX header (and add a blank line below).

NOTE: Problems with various packages used to generate diagrams, images or similar can be resolved by first externalising the results of these packages as standalone PDFs using the document class standalone and then embedding the PDFs as images instead of the code used to generate them. See also the FAQ How do I use the standalone class to create separate images?

With the standalone class, any TeX code, e.g. for generating a graphic or diagram, can be converted into a separate PDF. This image can then be easily integrated into the main document as usual using \includegraphics command.

1. Create a TeX file using the standalone class, e.g. with the following basic structure:

   \documentclass{standalone}
   \usepackage{xyz}
   
   \begin{document}
   \begin{somepicture}
   \somedrawingcommands
   \end{somepicture}
   \end{document}
   

2. Save and compile this TeX file, e.g. as sample.tex (with the compile result sample.pdf)
3. Open the TeX file of your main document and include the resulting pdf, e.g. \includegraphics{sample.pdf}.

It is also possible to generate several images with one standalone file. To do this, you only need to define a corresponding environment in the documentclass option, e.g. \documentclass[multi=newFigure]{standalone}, and wrap the code for each of the separate images with this environment, so \begin{newFigure}…\end{newFigure}. To include the images into the main document, please use then the page option of the grahics command, e.g. \includegraphics[page=1]{sample.pdf}.

For more detailed instructions, please see the package document on CTAN. However, please don't use the commands provided by standalone package within the main document to include the separated code, e.g. \includestandalone[...]{sample.tex} as this is currently not yet supported by our LaTeX processing workflow. Instead please include the pre-compiled, resulting PDF.

• 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.

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.

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

• 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).

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!

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}, swhid={...}]{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.)
• The swhid (Software Heritage identifier) is optional and will usually be added by the publisher.

Please note:

• In case of a resource that may evolve over time (e.g., source code under active development), sufficient details must be provided for readers to find the specific relevant version.
• Relevant materials can be referred to via URLs (either directly in the text or in footnotes) or via a bibliographical reference in the text. Please ensure any URLs are formatted as such, i.e., clickable in the digital version of the article to visit the relevant page.
• Relevant resources included in this statement must be well-documented or otherwise self-explanatory for readers viewing the materials.
• Resources should be published in such a way that enables long-term availability via persistent links; for example, use of archival platforms such as arXiv, Figshare, Zenodo, etc. is encouraged. Established platforms such as Github are also acceptable for source code and other materials. We discourage the use of platforms not intended for long-term publication, such as a personal homepage, file-sharing services (DropBox, Google Drive), etc. Company, personal and (non-archival) institutional platforms are also not suitable for archival purposes, but they can be used to host live demonstrations and services when accompanied by source code, data, and/or long-term archiving of a static snapshot.

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.

• 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.

The metadata associated with a DOI may not be available in all services, especially in the context of Crossref. The reason for this is that we use DataCite as our DOI registry and not CrossRef. CrossRef is certainly the largest registry for DOIs, but there are a few others (see https://www.doi.org/the-community/existing-registration-agencies/).

However, our data can be retrieved in a number of ways. DataCite offers several search options and APIs that are similar to those of CrossRef, see for example https://commons.datacite.org/.

Alternatively, you can of course retrieve the complete set of metada directly from us (https://drops.dagstuhl.de/metadata) or the basic data set from dblp (https://dblp.org).

• 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.

You may wonder why algorithms appear as vector graphics in the HTML version of many documents instead of being an integral part of the HTML output. The reason is the following:

Algorithms combine graphics-like output and text in a way that an accurate HTML-conversion is difficult to obtain in the general case. In particular, we observed major layout issues regarding nested structures (e.g., loops, conditionals, ...) and noticed that the line numbers of the LaTeXML output often do not match the line numbers in the PDF (an inaccuracy which we consider not acceptable).

Whenever necessary by the above reasons, we prefer to embed algorithms as vector graphics (more precisely, as SVG) to guarantee in particular that line breaks and line numbering are consistent between the two document versions (PDF/HTML).

Our LaTeX-to-HTML conversion is based on the open-source tool LaTeXML, as is the case with arXiv.

Since not all LaTeX packages are supported by LaTeXML and many authors use custom macros or LaTeX hacks, it may frequently happen that the direct LaTeXML output contains unacceptable display errors. In severe cases, HTML generation fails completely.

As arXiv also points out, the quality of the HTML output depends largely on best practices in LaTeX use (see arXiv: Submit LaTeX Best Practices).

We collect suggestions for authors on how to create LaTeX that is as suitable as possible for HTML generation in the following FAQ:

• How can authors improve the HTML output of their publications?

Based on feedback from authors, we document the most common problems there and try to gradually expand coverage.

In order to improve the resulting HTML and increase coverage, and to meet our high quality standards as well as those of our authors and readers, Dagstuhl Publishing - unlike arXiv - relies on a semi-automatic transformation process: First, we attempt to resolve incompatibilities manually (at the LaTeX level) in order to enable or improve the conversion. Subsequently, a visual check is performed to identify and correct remaining inconsistencies. This significant additional effort is very promising but also cost-intensive.

Of the over 1000 documents processed so far, 90% have been successfully converted into HTML suitable for publication. However, the significant additional costs are currently not covered by the APC, which already barely covers costs. HTML conversion is therefore currently being run as an experimental project. Only after a thorough evaluation of the project after a minimum period of one year, a decision will be made on whether to continue HTML support.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

PDF remains the primary output format at Dagstuhl Publishing. However, starting in 2025, we will also offer HTML, as HTML content is significantly more accessible on screen readers, screen magnifiers, and mobile devices. While PDFs were developed primarily for true-to-print display, HTML allows for flexible adaptation to users with different needs (e.g. enlarged text, high-contrast display or linear reading aloud by screen readers).

By providing HTML, we want to break down barriers and improve access to our publications.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

HTML (or XML) currently offers the most reliable way to make document content accessible:

• Support from assistive technologies: Screen readers and magnification software can interpret HTML content much better than PDF.
• Structured presentation: HTML allows clear semantic markup (headings, lists, tables, formulas), which is crucial for barrier-free use.
• Flexible use: Content adapts to different devices and screen sizes – a clear advantage for mobile use.

ArXiv also refers to HTML as the most promising way to make scientific content accessible (see arXiv HTML as an accessible format for papers).

See also the related FAQ "Why are we not (yet) using PDF/UA as an accessible format?"

The quality of the HTML output depends heavily on how consistent and standard-compliant a LaTeX document is structured. Some packages or self-defined macros can make conversion difficult or impossible. The following tips are based on arXiv's best practices:

1. Use standard LaTeX
   • Use the document classes and packages Dagstuhl Publishing provides whenever possible.
   • Avoid unnecessary LaTeX hacks or workarounds that are not documented.
2. Maintain semantic structure
   • Mark headings with \section, \subsection, etc. – not just with manual formatting (\textbf, \large).
   • Do not set numbering manually, but use the designated LaTeX commands (enumerate environments).
3. Set mathematical expressions and formulas correctly
   • Always write mathematical expressions in $...$ (inline) or \[...\] / equation environments.
   • Define your own macros sparingly and comprehensibly.
4. Mark tables and figures appropriately
   • Create tables with the tabular environment and, if possible, without exotic extensions.
   • For figures, use \includegraphics in a figure environment and – if possible – add \caption.
   • Specify alt text for figures: \includegraphics[alt={plain-text description of image}]{example-image-a}
5. Avoid incompatible packages
   • Some packages that deeply interfere with the layout (e.g. certain table or math packages) are problematic with LaTeXML.
   • If possible, don’t use additional packages or switch to generally supported packages.
   • See FAQ: Which packages cause problems with LaTeXML?

In short: The cleaner the structure of a LaTeX document, the more likely it is that the HTML conversion will be successful and of high quality.

There are various reasons why an HTML version of a document may not have been published (yet).

If the article (the PDF) was published only recently (up to 3 months ago), it is very likely that HTML production for the volume has not been completed. Once the HTML version has been published, all authors will be informed accordingly.

If your article (the PDF) was published after 1 January 2025 (and not within the last 3 months), the conversion of the article to HTML was probably unsuccessful. There may be various reasons for this. Please read the FAQs for more information:

• How can authors improve the HTML output of their publications?
• Which packages cause problems for LaTeXML?

Of course, you can also contact the publisher at any time.

Please note that there are currently no plans to retroactively generate HTML files for documents published before 2025.

PDF/UA (Universal Accessibility) is the ISO standard for accessible PDF documents. Since 2021, our publications have been published in PDF/A (Archivable) format, which is optimised for long-term archiving. In theory, it is possible to create a document that is both PDF/A and PDF/UA compliant. In practice, however, this is currently hardly feasible with LaTeX, as the necessary tools and workflows are not yet mature.

The current status of the LaTeX project for creating Tagged PDF (the basis for PDF/UA) is still experimental (see LaTeX tagging project). A stable version does not yet exist. Before widespread use, extensive compatibility tests would also have to be carried out with the numerous LaTeX packages that our authors use in addition to the classes provided.

We evaluate developments regularly, but currently see no practical way of reliably generating PDF/UA with our LaTeX-based publication process.

LaTeXML already supports a large number of LaTeX packages, but not all of them. Please see this website for the list of packages currently supported by LaTeXML. As a general rule:

• All packages included in the document classes/styles offered by Dagstuhl Publishing are currently compatible with LaTeXML and are supported.
• Problems may arise if authors include additional packages that are not (yet) covered by LaTeXML.

In such cases, we recommend:

1. Checking whether the package is really necessary or whether there is an alternative that is already supported.
2. Contribute to the community: LaTeXML is public domain software and open to contributions from third parties.
   • Open issues and problems can be reported directly in the LaTeXML issue tracker on GitHub.
   • Information on collaboration can be found on the following websites: LaTeXML documentation, Porting LaTeX packages for LaTeXML, and How to Contribute.

In short: All packages provided by Dagstuhl Publishing as standard are safe. For additional packages, authors themselves or together with the LaTeXML community can contribute to improving support.

Here we collect packages that are currently incompatible, along with possible alternatives and workarounds:

• apxproof: Causes LaTeXml to fail. - Do not use, if possible. In particular, remove the package if no appendix is given. If it is only rarely used, try to move the proofs manually to the appendix.
• Proof-at-the-end: same as apxproof.
• kotex: Causes LaTeXml to fail. – Do not use unless strictly necessary.
• siunitx: Not supported by LaTeXml, leaves error messages in the produced HTML. – Do not use unless strictly necessary.
• derivative: Not supported by LaTeXml, leaves error messages in the produced HTML. – Try to use \frac and \partial instead, like \frac{\partial f}{\partial t}
• forest: Not supported by LaTeXml, can be externalized (see note below).
• kbordermatrix: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• mathpartir (inferrules): Not supported by LaTeXml, leaves error messages in the produced HTML. In very simple cases, use ordinary fractions instead. – externalization possible (see note below).
• minted: Try to avoid mintinline if possible unless strictly necessary. If you use it, try to avoid unicode symbols.
• nicematrix: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• prooftree: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• syntax: Not supported by LaTeXml, leaves error messages in the produced HTML. - Can be externalized (see note below).
• xy: Not supported by LaTeXml, leaves error messages in the produced HTML. - can be externalized (see note below).
• knowledge: Collect knowledge definitions in the LaTeX header (and add a blank line below).

NOTE: Problems with various packages used to generate diagrams, images or similar can be resolved by first externalising the results of these packages as standalone PDFs using the document class standalone and then embedding the PDFs as images instead of the code used to generate them. See also the FAQ How do I use the standalone class to create separate images?

With the standalone class, any TeX code, e.g. for generating a graphic or diagram, can be converted into a separate PDF. This image can then be easily integrated into the main document as usual using \includegraphics command.

1. Create a TeX file using the standalone class, e.g. with the following basic structure:

   \documentclass{standalone}
   \usepackage{xyz}
   
   \begin{document}
   \begin{somepicture}
   \somedrawingcommands
   \end{somepicture}
   \end{document}
   

2. Save and compile this TeX file, e.g. as sample.tex (with the compile result sample.pdf)
3. Open the TeX file of your main document and include the resulting pdf, e.g. \includegraphics{sample.pdf}.

It is also possible to generate several images with one standalone file. To do this, you only need to define a corresponding environment in the documentclass option, e.g. \documentclass[multi=newFigure]{standalone}, and wrap the code for each of the separate images with this environment, so \begin{newFigure}…\end{newFigure}. To include the images into the main document, please use then the page option of the grahics command, e.g. \includegraphics[page=1]{sample.pdf}.

For more detailed instructions, please see the package document on CTAN. However, please don't use the commands provided by standalone package within the main document to include the separated code, e.g. \includestandalone[...]{sample.tex} as this is currently not yet supported by our LaTeX processing workflow. Instead please include the pre-compiled, resulting PDF.

• 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.

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.

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

• 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).

• 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

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}, swhid={...}]{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.)
• The swhid (Software Heritage identifier) is optional and will usually be added by the publisher.

Please note:

• In case of a resource that may evolve over time (e.g., source code under active development), sufficient details must be provided for readers to find the specific relevant version.
• Relevant materials can be referred to via URLs (either directly in the text or in footnotes) or via a bibliographical reference in the text. Please ensure any URLs are formatted as such, i.e., clickable in the digital version of the article to visit the relevant page.
• Relevant resources included in this statement must be well-documented or otherwise self-explanatory for readers viewing the materials.
• Resources should be published in such a way that enables long-term availability via persistent links; for example, use of archival platforms such as arXiv, Figshare, Zenodo, etc. is encouraged. Established platforms such as Github are also acceptable for source code and other materials. We discourage the use of platforms not intended for long-term publication, such as a personal homepage, file-sharing services (DropBox, Google Drive), etc. Company, personal and (non-archival) institutional platforms are also not suitable for archival purposes, but they can be used to host live demonstrations and services when accompanied by source code, data, and/or long-term archiving of a static snapshot.