
Dagstuhl Manifestos
Dagstuhl Perspectives Workshops complement Dagstuhl Seminars. They look beyond recent research far into the future, trying to identify new goals, fields and applications of computer science. The scope of Dagstuhl Perspectives Workshops includes reflection about the state of individual or overlapping fields.
Dagstuhl Perspectives Workshops are more oriented towards a small group of internationally renowned senior researchers for an intensive discussion with a focus on strategy. In contrast to Dagstuhl Seminars they do not refer to their current research results but reflect the state of a field, identify strengths and weaknesses, determine promising new developments and relevant new problems, and seek synergies between different fields.
Initiated in 2011, the series Dagstuhl Manifestos publishes the manifestos resulting from Dagstuhl Perspectives Workshops.
The journal Dagstuhl Manifestos is published in one volume with one issue per year.
Publications

Moreover, all papers are indexed in dblp: DagMan @ dblp
Aims and Scope
The manifestos from Dagstuhl Perspectives Workshops are published in the journal Dagstuhl Manifesto.
The goal is to describe the state-of-the-art in a field along with its shortcomings and strenghts. Based on this, position statements and perspectives for the future should be described.
A manifesto typically has a less technical character; instead it provides guidelines and roadmaps for a sustainable organization of future progress.
Open Access Policy
License
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
ISSN
Identifier
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
Publication Ethics
Editorial Board
- Elisabeth André Universität Augsburg, DE
- Franz Baader TU Dresden, DE
- Goetz Graefe Google - Madison, US
- Reiner Hähnle TU Darmstadt, DE
- Barbara Hammer Universität Bielefeld, DE
- Lynda Hardman CWI - Amsterdam, NL and University of Utrecht, NL
- Holger Hermanns Schloss Dagstuhl – Wadern, DE and Universität des Saarlandes – Saarbrücken, DE - Scientific Director
- Steve Kremer INRIA Nancy - Grand Est, FR
- Rupak Majumdar Max-Planck-Institut für Softwaresysteme – Kaiserslautern, DE
- Heiko Mantel TU Darmstadt, DE
- Lennart Martens Ghent University, BE
- Albrecht Schmidt LMU München, DE
- Wolfgang Schröder-Preikschat Universität Erlangen-Nürnberg, DE
- Heike Wehrheim Universität Oldenburg, DE
- Verena Wolf Universität des Saarlandes - Saarbrücken, DE
- Martina Zitterbart KIT - Karlsruher Institut für Technologie, DE
Constitution
The Scientific Directorate of Schloss Dagstuhl acts as editorial board. The task of the Scientific Directorate is to implement the Center's designated purpose in a scientific and subject-matter capacity. It convenes twice a year to establish the research and event program, ensure the quality of the Center's offerings, and monitor how the program is put into practice.
Members of the Scientific Directorate are the Scientific Director and as many scientific experts as necessary and appropriate for the competent evaluation of important computer science fields.
Members of the Scientific Directorate are appointed by the Supervisory Board following a joint proposal by the Scientific Director and the Scientific Advisory Board. Proposals are collated by the Scientific Director in collaboration with the Scientific Advisory Board based on proposals from the shareholders, the Scientific Directorate, and the Scientific Advisory Board.
Info for Authors
The composition of Dagstuhl Manifestos is highly individual. It is up to the organisers of the Perspectives Workshop, who also act as editors of the Manifesto, to organise the composition of the Manifesto. Therefore, manifesto authors should contact the editors directly for further information.
FAQ
HTML
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:
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:
- Use standard LaTeX
- Use the document classes and packages Dagstuhl Publishing provides whenever possible.
- Avoid unnecessary
LaTeX hacks
or workarounds that are not documented.
- 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).
- Mark headings with
- Set mathematical expressions and formulas correctly
- Always write mathematical expressions in
$...$
(inline) or\[...\]
/ equation environments. - Define your own macros sparingly and comprehensibly.
- Always write mathematical expressions in
- 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}
- 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:
- Checking whether the package is really necessary or whether there is an alternative that is already supported.
- 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.
- 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}
- Save and compile this TeX file, e.g. as sample.tex (with the compile result sample.pdf)
- 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.
as this is currently not yet supported by our LaTeX processing workflow. Instead please include the pre-compiled, resulting PDF.\includestandalone[...]{sample.tex}
Not found?
Didn't find what you are looking for? Don't hesitate to leave us a message at publishing@dagstuhl.de!
Templates and Example Files
Please download the current version of the DagMan style along with an example file:
For older releases and an issue tracker, see our GitHub archive.
Editorship / Authorship
The organizers of the Dagstuhl Perspectives Workshop are going to act as editors of the manifesto. The authorship of each chapter/section written is appropriately mentioned in the manifesto.
FAQ
HTML
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:
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:
- Use standard LaTeX
- Use the document classes and packages Dagstuhl Publishing provides whenever possible.
- Avoid unnecessary
LaTeX hacks
or workarounds that are not documented.
- 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).
- Mark headings with
- Set mathematical expressions and formulas correctly
- Always write mathematical expressions in
$...$
(inline) or\[...\]
/ equation environments. - Define your own macros sparingly and comprehensibly.
- Always write mathematical expressions in
- 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}
- 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:
- Checking whether the package is really necessary or whether there is an alternative that is already supported.
- 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.
- 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}
- Save and compile this TeX file, e.g. as sample.tex (with the compile result sample.pdf)
- 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.
as this is currently not yet supported by our LaTeX processing workflow. Instead please include the pre-compiled, resulting PDF.\includestandalone[...]{sample.tex}
Not found?
Didn't find what you are looking for? Don't hesitate to leave us message at publishing@dagstuhl.de!
FAQ
General
Yes, we expect our Perspective Workshops to prepare a Dagstuhl Report and a Dagstuhl Manifesto.
The Dagstuhl Reports series aims at documenting a seminar/workshop; the report is not reviewed. See http://www.dagstuhl.de/dagrep.
(We expect the submission of the report 3 months after the workshop/seminar.)
A Dagstuhl Manifesto aims at describing the state of the art of the field and proposing visions and perspectives. The manifesto is reviewed by the scientific directorate of Dagstuhl. The manifesto targets both the scientific community and "political" stakeholders (such as funding agencies, EU departments, ...). See http://www.dagstuhl.de/dagman.
(We expect the submission of the manifesto ~6 months after the seminar.)
Not found?
Didn't find what you are looking for? Don't hesitate to leave us message at publishing@dagstuhl.de!
Recently published volumes
-
DagMan, Vol. 10, Issue 1, DagMan, Volume 10, Issue 1
-
DagMan, Vol. 9, Issue 1, DagMan, Volume 9, Issue 1
-
DagMan, Vol. 8, Issue 1, Dagstuhl Manifestos, Volume 8, Issue 1
-
DagMan, Vol. 7, Issue 1, Dagstuhl Manifestos, Volume 7, Issue 1
-
DagMan, Vol. 6, Issue 1, Dagstuhl Manifestos, Volume 6, Issue 1
-
DagMan, Vol. 5, Issue 1, Dagstuhl Manifestos, Volume 5, Issue 1
-
DagMan, Vol. 4, Issue 1, Dagstuhl Manifestos, Volume 4, Issue 1
-
DagMan, Vol. 3, Issue 1, Dagstuhl Manifestos, Volume 3, Issue 1
-
DagMan, Vol. 2, Issue 1, Dagstuhl Manifestos, Volume 2, Issue 1
-
DagMan, Vol. 1, Issue 1, Dagstuhl Manifestos, Volume 1, Issue 1