Journal

Transactions on Graph Data and Knowledge

ISSN 2942-7517

Volumes

Volume

Transactions on Graph Data and Knowledge, Volume 2

TGDK, Volume 2
  • Issue 1 - Special Issue on Trends in Graph Data and Knowledge - Part 2 (2024)
  • Issue 2 - Special Issue on Resources for Graph Data and Knowledge (2024)
  • Issue 3 (2024)
Volume

Transactions on Graph Data and Knowledge, Volume 1

TGDK, Volume 1
  • Issue 1 - Special Issue on Trends in Graph Data and Knowledge (2023)

News



Access Numbers


Authors

Transactions on Graph Data and Knowledge is a Diamond Open Access journal that publishes research contributions relating to the use of graphs for data and knowledge management.

Aims and Scope

Transactions on Graph Data and Knowledge (TGDK) is an Open Access journal that publishes original research articles and survey articles on graph-based abstractions for data and knowledge, and the techniques that such abstractions enable with respect to integration, querying, reasoning and learning. The scope of the journal thus intersects with areas such as Graph Algorithms, Graph Databases, Graph Representation Learning, Knowledge Graphs, Knowledge Representation, Linked Data and the Semantic Web. Also in-scope for the journal is research investigating graph-based abstractions of data and knowledge in the context of Data Integration, Data Science, Information Extraction, Information Retrieval, Machine Learning, Natural Language Processing, and the Web.

The journal is Open Access without fees for readers or for authors (also known as Diamond Open Access).

Open Access Policy
TGDK articles are peer-reviewed and published according to the principle of OpenAccess, i.e., they are available online and free of charge. The authors retain their copyright. Preprints (pre-review manuscripts), post prints (authors accepted manuscripts, AAM), and the version of record (VoR) can be deposited without restrictions.
License
Each article is published under a Creative Commons CC BY license (http://creativecommons.org/licenses/by/4.0/).
The metadata provided by Dagstuhl Publishing on its webpages, as well as their export formats (such as XML or BibTeX) available at our website, is released under the CC0 1.0 Public Domain Dedication license (https://creativecommons.org/publicdomain/zero/1.0/legalcode).
Processing Charge
No fees are charged for the journal TGDK, neither for authors nor for readers (also known as Diamond Open Access). This is made possible by support from the Semantic Web Science Association (SWSA).
ISSN
2942-7517
Identifier
Each issue is assigned a DOI and a URN.
Each article is assigned a DOI and a URN.
To facilitate author identification, the Open Researcher and Contributor ID (ORCID) must be provided for all authors when uploading so that authors can be uniquely linked to their ORCID iD.
Longterm Preservation
The digital archiving of each issue is done in cooperation with the Deutsche Nationalbibliothek/German National Library (http://www.dnb.de).
Publication Ethics
Dagstuhl Publishing as a division of Schloss Dagstuhl – Leibniz-Zentrum für Informatik GmbH (LZI, or Schloss Dagstuhl for short) and its series and journals adhere to CORE practices guidance laid by COPE (Committee on Publication Ethics) and are committed to the rules of good scientific practice in accordance with the guidelines of the Leibniz Association and the German Research Foundation (DFG). We expect all parties (so authors, editors, and reviewers) involved in the publication and review process of contributions to be published in the series to follow these core practises and the guidelines. Allegations of misconduct will be investigated in accordance with the COPE Best Practice Guidelines as far as is practicable. If notified of a potential breach of publication ethics, we encourage editors and authors to inform Dagstuhl Publishing contact as soon as possible. Detailed information can be found on the Publication Ethics website.
Editorial Board
Editors in Chief
Former Editor in Chief
Advisory Board Members
Associate Editors
Editorial Board Members
Constitution

Editors-in-Chief will serve for a maximum four-year term. TGDK will maintain four Editors-in-Chief throughout by electing a new person to the role each year. The new Editor-in-Chief will be chosen via (1) a candidate proposal process that will select from Associate Editors; (2) a vote amongst current Editors-in-Chief and an Advisory Board. The most senior Editor-in-Chief (longest serving) will have a casting vote in the case of a tie. More than one gender and continent must always be represented among the active Editors-in-Chief, which will be enforced, if necessary, during the candidate selection phase (ensuring that no matter the candidate chosen, these restrictions will be satisfied).

The TGDK Editorial Board consists of Associate Editors and Editorial Board Members. Associate Editors are primarily tasked with finding reviewers for submissions, preparing meta-reviews, and sending their recommended decisions to the Editors-in-Chief based on the reviews received. Editorial Board Members are principally tasked with providing high-quality and timely reviews for submissions. External reviewers may also be invited to review papers, as necessary. Aside from their contributions via the peer review process, Associate Editors and Editorial Board Members jointly support the journals in other ways: providing feedback through regular meetings on the directions of the journal, proposing and organizing Special Issues for the journal, organizing and participating in meet-ups at relevant conferences, etc. All Editorial Board members and Associate Editors will serve four year terms, with the possibility of up to two renewals in this particular role.

Aside from the Editorial Board members, Associate Editors and Editors-in-Chief, TGDK will also have Advisory Board members, and Executive Board members. Advisory Board members are senior academics in the community who are broadly experienced in academic matters, in running journals, etc. At most eight people will serve on the Advisory Board and each member serves for at most an eight year (non-renewable) term. When an Editor-in-Chief reaches the end of their term limit, or retires for other reasons, they will be invited to join the Advisory Board; the longest-serving Advisory Board member will retire, if necessary, to make room. The Advisory Board will meet with the Editors-in-Chief once a year (possibly a virtual meeting) to review the past year of the TGDK journal and to discuss future plans and strategies.

The Executive Board of TGDK is then the combination of the Advisory Board and the active Editors- in-Chief of the journal. Based on the term limits of four years for Editors-in-Chief and eight years for Advisory Board members, the implied term limit for the Executive Board is twelve years.

Review Criteria

TGDK currently solicits two types of contributions:

  • Research articles: Such articles present novel research contributions that advance the state-of-the-art in their respective area. The criteria that apply to such articles include:
    • Novelty: The originality of the research contribution must be clearly identified in relation to the pertinent research literature.
    • Relevance: The topic of the article must be compatible with TGDK's Call for Papers.
    • Impact: The research described by the article must be well-motivated and have the potential to generate impact in a research and/or practical setting.
    • Technical soundness: The article must be factual, correct and free from inaccurate or unjustified claims.
    • Reproducibility: In the case of experimental contributions, the article must provide enough details (possibly in conjunction with supplementary material) in order to permit the results to be replicated; in case this is not possible, the authors must clearly justify why.
    • Clarity: The article must be well-written and understandable.
  • Survey articles: Such articles present a novel, systematic and comprehensive synthesis of published research works within a chosen scope. The criteria that apply to such articles include:
    • Novelty: The survey must involve an original scope, and/or must otherwise justify its added contributions over other surveys with a similar scope.
    • Relevance: The topic of the article must be compatible with TGDK's Call for Papers.
    • Scope: The scope of the survey and the criteria for inclusion/exclusion of relevant papers must be clearly defined.
    • Completeness: The survey must provide a comprehensive synthesis of the literature pertinent to the scope.
    • Clarity: The article must be well-written, understandable and accessible to newcomers to the area.
  • Resource articles: Such articles present a detailed description of a resource relevant in a research context. The criteria that apply to such articles include:
    • Novelty: The submission must describe a novel resource that adds value over other available resources; if a previous submission has been published about the resource, we expect the submission to describe substantial novel features.
    • Relevance: The topic of the submission must be relevant to TGDK's research scope, as described in the Call for Papers.
    • Clarity: The submission must be well-written, understandable, self-contained, accessible and contain all of the details required by this Call.
    • Technical soundness: The submission must be technically sound, and the resource described must be technically sound.
    • Impact: The submission must describe a resource that has generated substantial impact. In the case of mature resources, impact is measured through the adoption and use of the resource by third parties, as described in the article. In the case of emerging resources, impact is measured by the scientific insights that it provides, as described in the article.
    • Resource quality: Reviewers will be asked to look over the resource itself: to ensure that it is available, well-documented, technically sound, licensed, sustainable, of high quality, follows best practices, conforms to what is described in the submission, etc.
Review Process
Regular Submissions
  • The Review Process is managed by the Editors-in-Chief (EiCs), Associate Editors (AEs), Editorial Board Members (EBMs) and External Reviewers (ERs). EiCs, AEs and EBMs are listed in the editorial board tab.
  • Exceptions to this Review Process are only permitted if passed by an EiC vote.
  • EiCs, AEs, EBMs and ERs must not participate in the Review Process for submissions on which they have a Conflict-of-Interest.
  • Submissions are by default single-blind with authors indicating their identity in the paper, while reviewers remain anonymous.
  • Upon submitting a paper, the authors may indicate persons that they deem to be unsuitable for reviewing their manuscript (for example, due to bias, conflicts-of-interest, interpersonal issues, etc.). A justification must be provided in each such case. This information will only be shared among the Editors-in-Chief and the assigned editor(s) for the submission.
  • Upon submission of a manuscript, an EiC assigns themselves to a paper. The assigned EiC can choose to Desk-Reject a paper, or invite an AE to be editor. Exceptionally, the assigned EiC may choose to invite an EBM to be editor.
  • The editor can recommend to the EiC to Desk-Reject a paper. Otherwise the editor should find a minimum of three reviewers for a paper. Reviewers can be EBMs, or can be external to the EB, i.e., External Reviewers (ERs).
  • Reviews are expected within four weeks of acceptance of a review invite, but the editor can choose to offer reviewers more time.
  • Upon receiving three reviews that the editor considers to be of high quality, the editor should submit a decision letter to the assigned EiC justifying one of four recommendations: Reject, Major Revision, Minor Revision, Accept.
  • In case that a paper receives two Reject recommendations, the editor may choose to submit a decision letter rejecting the paper without receiving a third review.
  • The assigned EiC should forward the editor's decision letter to the authors.
  • Resubmissions of Major Revisions are expected within eight weeks of sending a decision letter. Resubmissions of Minor Revisions are expected within four weeks. The editor can choose to offer authors more time for resubmission.
  • Resubmissions are expected to include a detailed response letter replying to the comments of the reviewers and editor, indicating and justifying the changes implemented (if any).
  • The editor will decide which reviewers to (re)invite for reviewing resubmissions (if any).
  • Upon resubmission of a Major Revision, if the editor’s recommendation is a second Major Revision, the manuscript will rather be rejected (“Two-Strike Rule”).
  • Papers that are rejected cannot be resubmitted within one year of the rejection notification, independently of changes made to the paper. An EiC can rule when a submission is a resubmission.
Special Issues
  • Proposals for Special Issues can be submitted to EiCs, and should include the names of the Guest Editors, the title of the Special Issue, and a proposed Call for Papers.
  • Special Issues can be approved (potentially subject to changes) via an EiC vote.
  • Guest Editors will assign themselves as editors of submissions to the corresponding Special Issue. The Review Process for Regular Submissions will then be followed.
  • Guest Editors cannot submit to their own Special Issue and must not participate in the Review Process for submissions on which they have a Conflict-of-Interest.
Regular Call for Papers

(Here we provide the Regular Call for Papers. See also our list of Special Issues open for submissions.)

Transactions on Graph Data and Knowledge is an Open Access journal that publishes research contributions relating to the use of graphs for data and knowledge management. Such contributions may be experimental or theoretical in nature, where submissions that combine both aspects are particularly welcome. The journal thus welcomes submissions from research communities – such as Graph Analytics and Algorithms, Graph Databases, Graph Representation Learning, Knowledge Graphs, Semantic Web – that provide novel insights into the use of graphs for generating, representing and managing data and knowledge. Likewise contributions relating to the use of graphs in the context of Big Data, Data Integration, Data Science, Information Extraction, Information Retrieval, Knowledge Representation, Machine Learning, Natural Language Processing, etc., are welcome.

We welcome the following types of submissions:

  • Research Articles present novel research contributions that advance the state-of-the-art in their respective area. They are reviewed based on novelty, relevance, impact, technical soundness, reproducibility and clarity.
  • Survey Articles present a novel, systematic and comprehensive synthesis of published research works within a chosen scope. They are reviewed based on novelty, relevance, scope, completeness and clarity.
  • Resource Articles (please see detailed description) present a detailed description of a resource relevant in a research context; key examples include a benchmark, knowledge graph, online system, ontology, specification, tool, etc. They are reviewed based on novelty, relevance, clarity, technical soundness, impact and resoure quality. We solicit two types of resource submissions:
    • Mature resources that have already enjoyed significant adoption by third parties.
    • Emerging resources that have only recently been made available, but that provide novel scientific results.

Topics in-scope for the journal include, but are not limited to, research relating to graph data & knowledge in the context of:

  • Graph Database Management Systems
    • Graph Storage & Indexing
    • Graph Query Processing & Query Optimizations
    • Graph Query Languages
    • Graph Database Theory
    • Graph Schema and Constraint Languages
    • Graph Database Security, Privacy & Access Control
    • Distributed/Federated Graph Queries
    • Evolution and Dynamics of Graph Databases
    • Analytics for Graph Databases
  • Semantic Web
    • Web Data Integration
    • Linked Data & Vocabularies
    • RDF-based Data Management
    • Ontology & Rule Languages
    • Ontology Engineering
    • Ontology & Entity Alignment
    • Validating Graph Data
    • Data Interoperability
    • Web Services
  • Graph-based Learning
    • Graph Representation Learning
    • Knowledge Graph Embeddings
    • Generative Graph Models
    • Learning in Graph Databases
    • Neuro–Symbolic Models
    • Natural Language Processing & Generation
    • Large Language Models meet Graphs
    • Multi-Modal Representations
    • Agent-based Systems
    • Graph-based Explainable AI
    • Theory of Graph-based Learning & AI
  • Knowledge Graphs
    • Knowledge Graph Construction
    • Knowledge Graph Completion & Curation
    • Knowledge Graph Management
    • Knowledge Graph Summarisation
    • Knowledge Graph Interfaces
    • Knowledge Graph Exploration
    • Knowledge Graph Question Answering
    • Personal Knowledge Graphs
    • Contextual Knowledge Graphs
    • Knowledge Graph Interoperability & Alignment
    • Access, Privacy, Security
    • Graph Algorithms & Theory for Knowledge Graphs
  • Knowledge Representation
    • Formal Logics & Languages
    • Reasoning Algorithms
    • Contextual Semantics
    • Uncertain or Conflicting Knowledge
    • Evolving & Dynamic Knowledge
    • Stream Reasoning
    • Theory of Knowledge Representation
  • Ordinal Structures
    • Ontologies & Taxonomies
    • Ontology Learning
    • Mining Directed Acyclic Graphs
    • Knowledge Discovery & Machine Learning on Ordinal Data
    • Formal Concept Analysis
    • Graph-based Conceptual Modelling
  • Applications of Graph Data & Knowledge
    • Bibliometrics & Libraries
    • Big Data
    • Commerce & Manufacturing
    • Cultural Heritage
    • Data Integration & Enrichment
    • Data Science
    • Education
    • FAIR & Open Science
    • Finance
    • Geospatial Systems
    • Government
    • Information Extraction & Retrieval
    • Law & Compliance
    • Life Sciences
    • Mobile & Personal Technologies
    • Multimedia & Multi-modal Data
    • Network Analysis
    • Social Sciences & Media
    • Streams, Sensors & Internet of Things
    • User Interfaces and Accessibility
    • The Web

Submissions on other research topics where graphs play a central role as a representation for data or knowledge are also welcome.

As a Diamond Open Access journal, official versions of accepted papers (as accessible via DOI) are published and made available for free online without fees for authors nor readers.

Resource Articles

Resources play an essential role in various aspects of Computer Science research. In the context of Graph Data & Knowledge, such resources may include benchmarks, datasets, engines, frameworks, interfaces, knowledge graphs, languages, ontologies, pre-trained models, software libraries, standards, tools, user logs, web applications and services, etc. Unfortunately, despite the advances that such resources enable, the work invested into creating and maintaining them is often undervalued in a research setting.

Transactions on Graph Data and Knowledge (TGDK) solicits journal articles that describe in detail a resource relevant to research on Graph Data & Knowledge per the topics described in TGDK’s Call for Papers. Specifically, we solicit articles describing two types of resources:

  • Mature resources that have already enjoyed significant adoption by third parties (not sharing an affiliation with those involved in creating or maintaining the resource). Such adoption may be in, for example, the context of research, industry or a specific user community. Conversely, it is not necessary for submissions to present a novel research contribution (e.g., to explore a novel hypothesis, to present novel experiments, to prove a novel theorem, etc.).
  • Emerging resources that have only recently been made available, but that provide novel scientific results. An example of such a resource could be, for example, a bespoke benchmark that gains novel insights into the performance of state-of-the-art tools on a specific task. The scientific contribution of the emerging resource must be made explicit, and the associated results presented in a manner enabling reproducibility.

We require that resource articles submitted to TGDK be written primarily by those involved in the creation and/or maintenance of the resource described. We further require—unless otherwise strongly justified by the submission, e.g., for ethical or legal reasons—that the resource be made available on the Web following best practices prior to submission, that it be linked from the submission, and that it be made available for third-party research works under an open license.

In case you have any doubts about the suitability of a particular article or resource for this call, please contact the Editors-in-Chief.

Content

Though there are no fixed upper or lower page limits, we expect submissions to this Call to be in the range of 10–20 pages using TGDK’s single column LaTeX template (see Author Instructions). We expect submissions to describe (at least) the rationale behind the creation of the resource, a technical description of the resource, the relevance to Graph Data & Knowledge, key statistics or other metadata underlying the resource and its adoption, how the resource is made available (including location, licensing, best practices adopted, etc.), how the sustainability of the resource is assured (for example, in terms of how it is published, how often it is updated, the community supporting it), an assessment of the limitations of the resource, and future directions for the resource. Descriptions of mature resources must also include a survey of how the resource is being used by third-parties. Descriptions of emerging resources must also describe novel scientific results gained through the use of the resource. Additional material to help validate the novelty, value or quality of the resource is also welcome, including experiments, theorems, etc.

In case the resource has been described in a previous publication, we expect the submission to cite this previous publication, and to clearly indicate the advances made since that prior publication as described by the current submission. Pre-prints with informal publication (e.g., on arXiv) do not count as a previous publication; in other words, we welcome submissions based on articles that have only been informally published as pre-prints. We do not accept submissions that are under review elsewhere.

Review Criteria

Submissions will undergo a standard peer review process, but will be subject to distinctive criteria, as follows:

  • Novelty: The submission must describe a novel resource that adds value over other available resources; if a previous submission has been published about the resource, we expect the submission to describe substantial novel features.
  • Relevance: The topic of the submission must be relevant to TGDK's research scope, as described in the Call for Papers.
  • Clarity: The submission must be well-written, understandable, self-contained, accessible and contain all of the details required by this Call.
  • Technical soundness: The submission must be technically sound, and the resource described must be technically sound.
  • Impact: The submission must describe a resource that has generated substantial impact. In the case of mature resources, impact is measured through the adoption and use of the resource by third parties, as described in the article. In the case of emerging resources, impact is measured by the scientific insights that the resource provides, as described in the article.
  • Resource quality: Reviewers will be asked to look over the resource itself: to ensure that it is available, well-documented, technically sound, licensed, sustainable, of high quality, follows best practices, conforms to what is described in the submission, etc.
Publication

As a Diamond Open Access journal, official versions of accepted TGDK articles (as accessible via DOI) are published by Dagstuhl Publishing and made available for free online without fees for authors nor readers. Dagstuhl Publishing also provides means to publish resources, which can be used by authors to ensure the long-term sustainability and archiving of their work. Upon acceptance of the publication, we may request additional metadata about the resource from the authors (contributors, web location, documentation, version info, licensing, etc.).

Special Issues

The following special issues are currently open for submissions:

The following special issues are closed for submissions:

Special Issue
Autonomous Systems and Knowledge Graphs

Over the past decade, Knowledge Graphs (KGs) have gained popularity in mainstream software engineering and are now being exploited in large-scale socio-technical information systems. Increasingly, these systems are decentralised, comprise autonomous entities interacting with humans, and facilitate inter-organisational cooperative behaviour of varying complexity, in particular on the Web. Furthermore, these systems push the limits of current solutions, architectures, and frameworks that implement autonomous behaviour. Consequently, new theoretical and engineering challenges arise; e.g. serendipity of the interaction methods, heterogeneity in knowledge, data and assumptions, standards and protocol implementations, and the emergence of novel cooperation and normative mechanisms, to name a few.

Scope

This special issue seeks novel work that tackles theoretical and engineering challenges related to human and machine autonomy benefiting from KGs, including (but not exclusively):

  • Architecture characteristics for autonomy exploiting KGs:
    • Openness, diversity, and heterogeneity
    • Serendipity and emergence
    • Control, trust, and reputation
    • Decentralised data management and querying
  • Incomplete or conflicting knowledge, beliefs, and assumptions and KGs:
    • Reconciliation and negotiation mechanisms
    • Reasoning with conflicting, uncertain, and/or incomplete knowledge
    • Human augmentation of reasoning and decision making
    • Argumentation, dialogues, and narratives
    • Human-machine and machine-human persuasion
    • Human-machine reasoning explainability
  • Human-machine social interactions and KGs:
    • Emergence of communication protocols through interactions
    • Legal and ethical technical foundations of Web-based autonomy
    • Governance, accountability, and explainability
    • Trust and Transparency
    • Representations of human agents versus genuinely artificial agents
    • Reasoning and learning / acting on the Web by example
    • Reasoning with disparity of capabilities
    • Regulating human-machine interactions
  • Development platforms and frameworks for autonomy exploiting KGs:
    • Requirements for KG compliance
    • Reasoning with services, things, tasks, and capabilities
    • Autonomy in standards pertaining to KGs and the Web: challenges and limitations
    • Verification and testing of autonomous systems utilising KGs or the Web
  • Use cases:
    • KGs for digital twins and distributed organisations
    • KGs for agents on the Semantic Web
    • KGs for agents in Web of Things-based use cases
    • Next generation of data infrastructure (e.g., cloud & edge computing, GAIA-X)
Guest Editors
  • Timotheus Kampik, SAP & Umeå University
  • Sabrina Kirrane, Vienna University of Economics
  • Terry Payne, University of Liverpool
  • Valentina Tamma, University of Liverpool
  • Antoine Zimmermann, École des Mines de Saint-Étienne
Timeline
  • Submission deadline: 31 August 2024
  • Author notification: 31 October 2024
  • Revisions: 31 November 2024
  • Author notification: 15 January 2025
  • Publication: Q1 2025
Submission
Please follow the submission instructions for TGDK.

As a Diamond Open Access journal, official versions of accepted papers (as accessible via DOI) are published and made available for free online without fees for authors nor readers.

Special Issue
Resources

Resources play an essential role in various aspects of Computer Science research. In the context of Graph Data & Knowledge, such resources may include benchmarks, datasets, engines, frameworks, interfaces, knowledge graphs, languages, ontologies, pre-trained models, software libraries, standards, tools, user logs, web applications and services, etc. Unfortunately, despite the advances that such resources enable, the work invested into creating and maintaining them is often undervalued in a research setting.

In this Call for Resource Papers, we solicit submission of journal articles that describe in detail a resource relevant to research on Graph Data & Knowledge per the topics described in TGDK’s Call for Papers. Specifically, we solicit articles describing two types of resources:

  • Mature resources that have already enjoyed significant adoption by third parties (not sharing an affiliation with those involved in creating or maintaining the resource). Such adoption may be in, for example, the context of research, industry or a specific user community. Conversely, it is not necessary for submissions to present a novel research contribution (e.g., to explore a novel hypothesis, to present novel experiments, to prove a novel theorem, etc.). Under this category, we also welcome submissions of novel, relevant resources that – while potentially not having notable impact yet – complement and enrich legacy resources or initiatives that have had major impact; we expect such submissions to involve the team of the legacy resource or initiative, for example, as coauthors.
  • Emerging resources that have only recently been made available, but that provide novel scientific results. An example of such a resource could be, for example, a bespoke benchmark that gains novel insights into the performance of state-of-the-art tools on a specific task. The scientific contribution of the emerging resource must be made explicit, and the associated results presented in a manner enabling reproducibility.

We require that the articles submitted to this Call be written primarily by those involved in the creation and/or maintenance of the resource described. We further require – unless otherwise strongly justified by the submission, e.g., for ethical or legal reasons – that the resource be made available on the Web following best practices prior to submission, that it be linked from the submission, and that it be made available for third-party research works under an open license.

Submission

In order to ensure that a resource is suitable for publication under this Call, the Editors-in-Chief of TGDK will provide a lightweight pre-check service for all resources prior to submission based on a brief description. If the resource is deemed relevant, the EiCs will invite the authors to submit their article, which will then undergo a thorough peer-review process. If not deemed relevant, we hope to have saved the authors time preparing a full submission on an out-of-scope resource. The pre-check description should be no more than 500 words, should be emailed to the TGDK Editors-in-Chief (tgdk@dagstuhl.de) prior to a full submission with the subject “TGDK Resource Pre-Check Service”, and should contain:

  • The name of the resource
  • Whether it is a mature or emerging resource
  • A brief description of the resource that also clarifies its relevance to research on Graph Data & Knowledge
  • Where it can be accessed and under what conditions
  • The authors of the proposed submission, and their contributions to the resource
  • For mature resources: up to five key instances where the resource or the legacy resource it complements has been used by third parties (in the context, for example, of research, industry, or a user community)
  • For emerging resources: a description of the scientific results derived using the resource, as will be detailed in the submission
  • Pointers to previous publications about the resource, if any, and the expected novel aspects to be described in the new publication

If the resource is deemed relevant, the Editors-in-Chief will instruct the authors on how to submit.

Content

Though there are no fixed upper or lower page limits, we expect submissions to this Call to be in the range of 10–20 pages using TGDK’s single column LaTeX template (see Author Instructions). We expect submissions to describe (at least) the rationale behind the creation of the resource, a technical description of the resource, the relevance to Graph Data & Knowledge, key statistics or other metadata underlying the resource and its adoption, how the resource is made available (including location, licensing, best practices adopted, etc.), how the sustainability of the resource is assured (for example, in terms of how it is published, how often it is updated, the community supporting it), an assessment of the limitations of the resource, and future directions for the resource. Descriptions of mature resources must also include a survey of how the resource is being used by third-parties. Descriptions of emerging resources must also describe novel scientific results gained through the use of the resource. Additional material to help validate the novelty, value or quality of the resource is also welcome, including experiments, theorems, etc.

In case the resource has been described in a previous publication, we expect the submission to cite this previous publication, and to clearly indicate the advances made since that prior publication as described by the current submission. Pre-prints with informal publication (e.g., on arXiv) do not count as a previous publication; in other words, we welcome submissions based on articles that have only been informally published as pre-prints. We do not accept submissions that are under review elsewhere.

Review Criteria

Submissions will undergo a standard peer review process, but will be subject to distinctive criteria, as follows:

  • Novelty: The submission must describe a novel resource that adds value over other available resources; if a previous submission has been published about the resource, we expect the submission to describe substantial novel features.
  • Relevance: The topic of the submission must be relevant to TGDK's research scope, as described in the Call for Papers.
  • Clarity: The submission must be well-written, understandable, self-contained, accessible and contain all of the details required by this Call.
  • Technical soundness: The submission must be technically sound, and the resource described must be technically sound.
  • Impact: The submission must describe a resource that has generated substantial impact. In the case of mature resources, impact is measured through the adoption and use of the resource by third parties, or the potential for impact by complementing or extending legacy high-impact resources, as described in the article. In the case of emerging resources, impact is measured by the scientific insights that it provides, as described in the article.
  • Resource: Reviewers will be asked to look over the resource itself: to ensure that it is available, well-documented, technically sound, licensed, sustainable, of high quality, follows best practices, conforms to what is described in the submission, etc.
Timeline
  • Pre-Checks: June 3, 2024
  • Submissions: July 1, 2024 (extended from June 20, 2024)
  • Author Notifications: August 31, 2024
  • Revisions: September 30, 2024
  • Author Notifications: October 31, 2024
  • Publication: Q4 2024

We encourage authors to perform the pre-check with the Editors-in-Chief as soon as possible, and potentially much earlier than the deadline of June 3.

Publication

As a Diamond Open Access journal, official versions of accepted TGDK articles (as accessible via DOI) are published by Dagstuhl Publishing and made available for free online without fees for authors nor readers. Dagstuhl Publishing also provides means to publish resources, which can be used by authors to ensure the long-term sustainability and archiving of their work. Upon acceptance of the publication, we may request additional metadata about the resource from the authors (contributors, web location, documentation, version info, licensing, etc.).

Editors

This Special Issue will be edited by the Editors-in-Chief of TGDK.

Special Issue Proposals
Transactions on Graph Data and Knowledge (TGDK) welcomes proposals for Special Issues (SIs) devoted to a specific topic that is within its scope. Successful proposals will focus on research or application areas of emerging significance or for which innovative and novel work is being done. For active SIs that are open for submission, or past SIs have concluded, please see the list of Special Issues.
Proposals
An SI proposal should include the following information:
  • Two or more people who will serve as the SI Guest Editors and work with the TGDK Editors-in-Chief and/or an Associate Editor to produce the issue. A short biography should be submitted for each. Please select one Guest Editor to be the lead point of contact.
  • A concise description of the SI topic along with a justification of why an SI is appropriate at this time.
  • A description of the research communities that the SI will draw from or be of interest to.
  • Any papers or authors that the SI Guest Editors intend to invite.
  • Any constraints or preferences for publication date.

Proposals should be sent to the Editors-in-Chief via email to tgdk@dagstuhl.de.

Timeline
The actual publication date and number of pages for accepted SI proposals will be decided by the EiCs in consultation with the SI Guest Editors and is subject to the constraints imposed by the publisher. A typical schedule will allow for three to six months before submissions are due, two months for the initial reviews, one month for subsequent revisions, and one month for a final version. A well expedited SI can complete in eight months.
Submissions

All SIs must have an open call for submissions to which members of the research community can respond by submitting papers. The SI Guest Editors are free, of course, to invite submissions. The SI Guest Editors will be expected to advertise the call in appropriate venues.

To avoid the appearance of a conflict of interest, the SI Guest Editors are expected not to submit papers to the SI or be a co-author on papers submitted. They are free, of course, to submit papers on the SI topic as regular papers to the journal.

Review Process

All papers, whether invited or submitted to a Special Issue, will undergo the same thorough review process used for regular papers submitted to the journal. This normally involves seeking reviews from three qualified reviewers. The SI Guest Editors will be responsible for recruiting potential reviewers prior to the submission due date and ensuring that their reviews are done in a timely manner and are of high quality.

The submission and review process must be carried out using the standard journal platform as indicated by the EiCs. This includes accepting initial submissions, recruiting and assigning reviewers, entering reviews, issuing decisions, submitting revised version and providing the final version of accepted papers.

When submissions are received, the SI Guest Editors should examine the papers to ensure that they are within scope, of appropriate length, and meet minimum standards for organization and readability. Papers that fail any of these criteria should be rejected without review by the SI Guest Editors. Papers that meet the criteria should be assigned to three reviewers, who should be given four to eight weeks to complete their reviews. After all of the reviews for a paper are completed, the SI Guest Editors should decide on one of the following results:

  • Reject: The paper will not be considered further.
  • Major revision: The paper requires significant changes before it can be accepted. These might include additional discussion, sections, analyses of data or even further experiments. If and when a revision is submitted it should be sent back to the original reviewers who will enter new reviews, typically within one month. When all of the reviews are in, the SI editors should then decide on one of reject, minor revision or accept, i.e., a second major revision decision should not be made.
  • Minor revision: Relatively small changes are required before the paper is accepted. When a revised version is received, the SI editors will review the paper to ensure that the changes were made rather than sending it back to the original reviewers.
  • Accept: The paper is accepted as is and requires no additional changes.

Final decisions of accepted papers must be approved by an EiC.

Instructions for SI Guest Editors
  1. It is worthwhile to do a first check with respect to the quality of the papers submitted. It is our experience that 25% or more of the paper submissions are outside the scope of SI or are of such low quality that it is not worthwhile to hand them over to reviewers. In such cases we suggest that you skim the paper and give two or three concrete reasons why the paper will not be acceptable by any means in its current form. This is sufficient to reject such papers. If the paper is outside the SI scope but looks to be of reasonable quality and within the scope of the journal, you can suggest that the authors consider re-submitting it as a regular paper.
  2. For all other papers we expect three detailed reviews. If you have a particularly expert reviewer in mind who might be overburdened with other tasks you might consider adding a fourth review to increase the chances of getting three reviews in time.
  3. For SI's we expect the following cycle:
    1. Original submission by authors: Papers are classified by SI Guest Editors as reject (frequent), major revision (frequent), minor revision (occasional), or accept (rare).
    2. Major changes by authors: The paper must be re-reviewed by the reviewers to see whether it is now acceptable. Sometimes reviewers have the opinion that papers can only get better and hence their judgement can only go up (e.g. from major to minor revision). This is of course wrong, if authors fail to meet expectations by reviewers a paper may have to be rejected after a major revision.
    3. Minor revision: These changes should usually be checkable by SI Guest Editors. If a paper is basically accepted and trivial changes are to be applied (e.g. typo correction), then a paper must not be classified as "accept" but rather as minor revision.
    4. Accept: From here on the paper goes into production for publication. Authors no longer have the possibility to change the paper, they can only correct mistakes inadvertently introduced via proofs supplied in the paper production process.
    EiCs usually accept SI Guest Editor decisions, but we keep an eye on all decisions with the following objectives:
    1. To have a process and decisions that are as transparent to authors as possible
    2. To not have decisions that are in stark contrast with reviewers' opinion – unless explained otherwise.
  4. Submission and acceptance rates: We do not enforce any kind of acceptance rate on SIs but we enforce high quality. The acceptance rate may depend on the maturity of the sub-community, the perceived breadth of the topic, and whether the call is likely to attract off-topic papers.
  5. We try to publish SI papers in a shorter time span. It can happen that a paper is very worthwhile, but needs a longer time for changes. In this case, rather than reject it, there is the option to redirect it to a normal issue of the journal under the rationale that we do not want to turn away good papers.
  6. If any question remains unanswered please to not hesitate to get in touch with us at: tgdk@dagstuhl.de
Submissions

To submit to TGDK, please proceed according to the following instructions:

  • Format your submission according to the LaTeX template available below. Please note that the review process is single anonymous, meaning that you should include the names of authors.
  • 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.
  • Ensure to include DOIs for paper references where available.
  • Submit your paper on our submission platform (this may require creating an account if you do not have one already). Be sure to select the correct submission type under “Section” (including Special Issue, if applicable).
Templates and Example Files

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

tgdk-v2021 v2021.2.2

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

Typesetting instructions - Summary

Transactions on Graph Data and Knowledge is a Diamond Open Access journal that publishes research contributions relating to the use of graphs for data and knowledge management.

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

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

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

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

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

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

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

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

FAQ
Submission

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

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

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

https://submission.dagstuhl.de/documentation/faq/24

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

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.
https://submission.dagstuhl.de/documentation/faq/2

  • 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.
https://submission.dagstuhl.de/documentation/faq/23

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.
https://submission.dagstuhl.de/documentation/faq/22

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.

https://submission.dagstuhl.de/documentation/faq/25

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

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

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

https://submission.dagstuhl.de/documentation/faq/7

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

https://submission.dagstuhl.de/documentation/faq/4

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.

https://submission.dagstuhl.de/documentation/faq/5

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.

https://submission.dagstuhl.de/documentation/faq/6
Author Approval

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

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

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

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

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

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

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

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

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

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

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

https://submission.dagstuhl.de/documentation/faq/27
Publication Workflow

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

Here is an example of a completely filled author macro:

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

Please note:

  • Use full first and last name.
  • City and country belong to the minimum requirements on an affiliation.
  • 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!
https://submission.dagstuhl.de/documentation/faq/41

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."
https://submission.dagstuhl.de/documentation/faq/17

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.
https://submission.dagstuhl.de/documentation/faq/22

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

https://submission.dagstuhl.de/documentation/faq/18

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
https://submission.dagstuhl.de/documentation/faq/16

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.

https://submission.dagstuhl.de/documentation/faq/20

Sample usage:

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

Please note:

  • comma as delimiter
  • first word and every proper noun should be capitalized
https://submission.dagstuhl.de/documentation/faq/15

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

https://submission.dagstuhl.de/documentation/faq/19

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

Sample usage:

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

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

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

https://submission.dagstuhl.de/documentation/faq/21

Not found?

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

Front Matter Template and Example Files

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

tgdkmaster-v2021 v2021.2.2
FAQ
Submission

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

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

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

https://submission.dagstuhl.de/documentation/faq/24

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

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.
https://submission.dagstuhl.de/documentation/faq/2

  • 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.
https://submission.dagstuhl.de/documentation/faq/23

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.
https://submission.dagstuhl.de/documentation/faq/22

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

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

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

https://submission.dagstuhl.de/documentation/faq/7

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

https://submission.dagstuhl.de/documentation/faq/4

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.

https://submission.dagstuhl.de/documentation/faq/5

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.

https://submission.dagstuhl.de/documentation/faq/6
Author Approval

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

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

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

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

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

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

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

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

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

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

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

https://submission.dagstuhl.de/documentation/faq/27
Publication Workflow

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

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

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

When approved, the volume will be officially published.

https://submission.dagstuhl.de/documentation/faq/31

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)
https://submission.dagstuhl.de/documentation/faq/29

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
https://submission.dagstuhl.de/documentation/faq/8
LaTeX Style

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

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

Please...

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

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.
https://submission.dagstuhl.de/documentation/faq/22

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

https://submission.dagstuhl.de/documentation/faq/18

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
https://submission.dagstuhl.de/documentation/faq/16

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.

https://submission.dagstuhl.de/documentation/faq/20

Sample usage:

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

Please note:

  • comma as delimiter
  • first word and every proper noun should be capitalized
https://submission.dagstuhl.de/documentation/faq/15

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

https://submission.dagstuhl.de/documentation/faq/19

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

Sample usage:

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

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

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

https://submission.dagstuhl.de/documentation/faq/21

Not found?

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

Contact TGDK

Editors-in-Chief and Editorial Management

tgdk@dagstuhl.de
Contact Dagstuhl Publishing

TGDK Team @ Dagstuhl Publishing

tgdk-office@dagstuhl.de
In which format should the bibliography be submitted?

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

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

Here is an example of a completely filled author macro:

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

Please note:

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

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

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

Please...

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

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

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

Please...

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

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

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

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

How to use the \keywords macro?

Sample usage:

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

Please note:

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

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

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

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

Questions / Remarks / Feedback
X

Feedback for Dagstuhl Publishing


Thanks for your feedback!

Feedback submitted

Could not send message

Please try again later or send an E-mail
© 2023-2024 Schloss Dagstuhl – LZI GmbH About DROPS Imprint Privacy Contact