default search action

• combined dblp search
• author search
• venue search
• publication search

Authors:

• no matches

• 

Venues:

• no matches

• 

Publications:

• no matches

• 

ask others

• Google
• Google Scholar
• Semantic Scholar
• Internet Archive Scholar
• CiteSeerX
• ORCID

As explained, dblp always indexes the tables of contents of complete proceedings or journal volumes in bulk. On this page you find a guideline on how to provide data of a complete volume in the dblp input format.

Usually, dblp seeks to obtain bibliographic meta data from the major publishers directly. Whenever this is not possible, dblp depends on the submission of data from individuals such as conference chairs and journal editors. The effort of these valuable helpers allows a timely inclusion of new proceedings or journal volumes to the data base which would otherwise have to wait in dblp 's priority queue. To allow for a convenient submission of publication data, a new XML based submission format has been developed. This comprehensive user's guide provides assistance on how to use this new format, and enables you to contribute high-quality meta data to dblp .

Introduction

dblp was started in 1993 as a purely handcrafted HTML application. Later essential parts were converted to XML, but the input "language" remained to be the same HTML-style language it has been in the 90s. Unfortunately, this old input format turned out to be quite cumbersome for irregular submitters of bibliographic meta data. With the new XML submission format, DBLP introduces a format that aims to be convenient and easy to understand.

In the past, submissions to dblp have occurred in many different ways and on many different quality levels. Time and resources at dblp are limited, so quite often the inclusion interesting scientific work had to be deferred since the additional work necessary to bring submitted data to a processible level could not be afforded. The new XML submission scheme is also an attempt to assist you in submitting data that is (almost) ready for inclusion. We hope that this will help to save time on both ends of the process and, therefore, allows for a timelier inclusion of your data to the dblp bibliography database.

XML submission format guidelines

This section introduces the new DBLP submission format by examples. A DTD or a XSD file describing the XML format can be found in the attachments

• dblpsubmission.dtd
• dblpsubmission.xsd

For excerpts from a DBLP submission file of a conference proceedings or journal volume, see the following code blocks. The complete example files can be found in the attachments:

• proceedings-example.xml
• journal-example.xml

The following summary provides a detailed explanation of the components of a valid DBLP submission file.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE dblpsubmission SYSTEM "https://dblp.org/xml/subm/dblpsubmission.dtd">
<dblpsubmission>
 <proceedings>
 <key>crypto</key>
 <editor>Tal Rabin</editor>
 <title>Advances in Cryptology - CRYPTO 2010.
 30th Annual Cryptology Conference.</title>
 <publisher>Springer</publisher>
 <year>2010</year>
 <isbn type="print">978-3-642-14622-0</isbn>
 <doi>10.1007/978-3-642-14623-7</doi>
 <conf>
 <acronym>CRYPTO</acronym>
 <number>30</number>
 <location>Santa Barbara, California, USA</location>
 <date>August 15-19, 2010</date>
 <url>https://www.iacr.org/conferences/crypto2010/</url>
 </conf>
 <series>
 <key>lncs</key>
 <title>Lecture Notes in Computer Science</title>
 <number>6223</number>
 </series>
 <toc>
 <section>Leakage</section>
 <publ>
 <author>Zvika Brakerski</author>
 <author>Shafi Goldwasser</author>
 <title>Circular and Leakage Resilient Public-Key Encryption
 under Subgroup Indistinguishability</title>
 <pages>1-20</pages>
 <doi>10.1007/978-3-642-14623-7_1</doi>
 </publ>
 <section>Lattice</section>
 <publ>
 <author>Chris Peikert</author>
 <title>An Efficient and Parallel Gaussian Sampler for Lattices.</title>
 <pages>80-97</pages>
 <doi>10.1007/978-3-642-14623-7_5</doi>
 </publ>
 </toc>
 </proceedings>
</dblpsubmission>

<dblpsubmission>
 <journal>
 <key>cacm</key>
 <title>Communications of the ACM</title>
 <short>Commun. ACM</short>
 <publisher>ACM</publisher>
 <address>New York</address>
 <issn type="print">0001-0782</issn>
 <issn type="electronic">1557-7317</issn>
 <url>https://cacm.acm.org/</url>
 <volume>
 <number>50</number>
 <issue>
 <number>1</number>
 <month>January</month>
 <year>2007</year>
 <toc>
 <text>The patent holder's dilemma: buy, sell, or troll?</text>
 <publ>
 <author>Diane Crawford</author>
 <title>Editorial pointers.</title>
 <pages>5</pages>
 <doi proxy="https://doi.acm.org/">10.1145/1188924</doi>
 </publ>
 <publ>
 <title>News track.</title>
 <pages>9-10</pages>
 <doi proxy="https://doi.acm.org/">10.1145/1188926</doi>
 </publ>
 <section>The business of software</section>
 <publ>
 <author>Phillip G. Armour</author>
 <title>Agile ... and offshore.</title>
 <pages>13-16</pages>
 <doi proxy="https://doi.acm.org/">10.1145/1188930</doi>
 </publ>
 </toc>
 </issue>
 </volume>
 </journal>
</dblpsubmission>

XML document root

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE dblpsubmission SYSTEM "https://dblp.org/xml/subm/dblpsubmission.dtd">
<dblpsubmission>
 <proceedings>
 ...
 </proceedings>
 <journal>
 ...
 </journal>
 ...
</dblpsubmission>

The DBLP submission file is an XML file in the 1.0 specification [7]. The file should consist entirely of utf-8 characters [6]. The root element of the DBLP submission file is a ‹dblpsubmission› element.

The ‹dblpsubmission› element may contain any number of ‹proceedings› elements (in case of conference or workshop proceedings volumes) or ‹journal› elements (in case of journal volumes). However, to keep things simple, we strongly recommend to create one XML file per submitted volume. Also, please consider using some expressive filenames.

The structure of ‹proceedings› and ‹journal› document fragments differ to some degree. Please refer to Section "Conference and workshop proceedings" and Section "Journals" for a detailed description of each type.

Conference and workshop proceedings  

 <proceedings>
 <key>crypto</key>
 <editor>Tal Rabin</editor>
 <title>Advances in Cryptology - CRYPTO 2010.
 30th Annual Cryptology Conference.</title>
 <publisher>Springer</publisher>
 <year>2010</year>
 <isbn type="print">978-3-642-14622-0</isbn>
 <doi>10.1007/978-3-642-14623-7</doi>
 <conf>
 ...
 </conf>
 <series>
 ...
 </series>
 <toc>
 ...
 </toc>
 </proceedings>

Conference series key

To allow for the correct indexing of a submitted proceedings volume, it is helpful if the key of the conference series is given enclosed in ‹key› tags (see How to find the key of a person, a publication, or a stream). At most one such ‹key› element must be given in a ‹proceedings› element. If the key of a conference series is unknown, or the series is new to dblp, the ‹key› element may be omitted.

Editor(s)

Editor names can be provided in ‹editor› tags. In case of multiple editors, a new ‹editor› element has to be given for each individual editor, e.g.:

<editor>Maurizio Lenzerini</editor>
<editor>Thomas Schwentick</editor>

When doing so, please preserve ordering of the editors as given in printed edition. If no editor is known for the given proceedings volume, the ‹editor› element may be omitted.

Matching a given name with the correct dblp person record is an important issue. If the editor is already known to dblp, please provide the name as it is stored in dblp. If you want to provide information on the uft-8 representation of the editor name, you can give them by using the optional attribute original, e.g.:

<editor original="&#24373;&#30495;&#35488;">Chin-Chen Chang</editor>

For more information on names in dblp, please read Why do person names ignore certain unicode characters, How does dblp handle first names, middle names, family names, non-western names and How to find the key of a person, a publication, or a stream.

Proceedings volume title

The title of the proceedings volume should be given enclosed in ‹title› tags. Each valid proceedings submission has to include exactly one ‹title› element that may not be omitted. Please use the title of the proceedings volume as given on the cover page, including any possible subtitles.

Publisher

The publisher of the proceedings volume can be given enclosed in ‹publisher› tags. If the publisher is unknown, then the ‹publisher› element may be omitted.

Year of publication

The year the proceedings volume is published is given enclosed in ‹year› tags. Each valid proceedings submission has to include exactly one ‹year› element. Note that the year of publication might differ from the actual year the conference took place.

ISBN

Any available ISBN [2] of the proceedings volume can be given enclosed in ‹isbn› tags. Sometimes, a proceedings volume has multiple ISBN for different versions of the publication, such as print and electronic editions. If multiple ISBN are known, a new ‹isbn› element can be given for each individual number. If the publication type of an ISBN is known, it can be specified using the optional attribute type, e.g.:

<isbn type="print">978-3-642-14622-0</isbn>

DOI of proceedings volume

Sometimes, a DOI [1] is assigned to a whole proceedings volume. In such a case, this DOI may be given using ‹doi› tags. Note that the DOI of individual papers are given in the ‹toc› element below. If a certain HTTP proxy server is preferred when handling this DOI, it may be specified using the optional attribute proxy, e.g.:

<doi proxy="https://dx.doi.org/">10.1007/978-3-642-14623-7</doi>

Conference/workshop details

 <conf>
 <acronym>CRYPTO</acronym>
 <number>30</number>
 <location>Santa Barbara, California, USA</location>
 <date>August 15-19, 2010</date>
 <url>https://www.iacr.org/conferences/crypto2010/</url>
 </conf>

Additional details on the conference or workshop are given in a single ‹conf› element. Every valid proceedings submission has to include exactly one ‹conf› element. The ‹conf› element may have the following child elements, of which only the ‹location› and ‹date› elements are mandatory:

• Acronym. If an acronym is commonly used for this conference or workshop, it may be given in a single ‹acronym› element. If no acronym is known, then this element may be omitted.
• Conference number. If the conference or workshop uses a consecutive numbering, the number of the iteration of this conference may be given enclosed in ‹number› tags. If no conference number is known, then this element may be omitted.
• Conference location. The location the conference took place is specified in a ‹location› element. Every valid proceedings submission has to include exactly one ‹location› element. Please use the format "City, State/Province (if applicable), Country" to specify this location. Please avoid giving the name of the actual conference site, such as names of hotels, conference centers, or universities.
• Date of the conference. The date the conference took place is given in ‹date› tags. Every valid proceedings submission has to include exactly one ‹date› element. Please us the format "Month Day, Year" or "Month fromDay-toDay, Year". Also, please use the non-abbreviated name of the month, not the number.
• URL of conference website. If this iteration of the conference has a website, its URL [5] may be given enclosed in ‹url› tags. If no website is known, then this element may be omitted.
• Part of other conference or event. If the conference or workshop takes place as part of or co-located with another conference or event, please let us know in an optional ‹partof› element. The content of this field can be any any freely formatted text describing the parent or co-located event. If available, you may also include an URL pointing to the parent or co-located event. If the conference or workshop does not take place as part of or co-located with another event, then this element may be omitted.

Series reference

 <series>
 <key>lncs</key>
 <title>Lecture Notes in Computer Science</title>
 <number>6223</number>
 </series>

Some conference or workshop proceedings are published as part of an ongoing series, such as Springer's Lecture Notes in Computer Science, the IFIP publication series, or the ACM International Conference Proceeding Series. In such a case, please provide information on the series using a ‹series› element.
This element may have the following child elements:

• Series key. In dblp, a key is assigned to each series. To allow for the correct indexing of a submitted proceedings volume, it is helpful if the key of the series is given enclosed in ‹key› tags (see How to find the key of a person, a publication, or a stream). If the key of the series is unknown, or the series is new to DBLP, the ‹key› element may be omitted.
• Series title. The title of the series should be given enclosed in ‹title› tags. Please use non-abbreviated title of the series. If a series is given, it has to contain a ‹title› element.
• Number in series. If the series uses some form of consecutive numbering, the number of the proceedings volume within this series may be given enclosed in ‹number› tags. If the no numbering scheme is used, then this element may be omitted.

Table of contents

The table of contents is provided in a single ‹toc› element. The structure of this element is the same for conference proceedings and journal volumes. Each valid DBLP submission has to provide exactly one ‹toc› element per ‹proceedings› element. For more information on the table of contents, please refer to Section "Table of contents" .

Journals  

 <journal>
 <key>cacm</key>
 <title>Communications of the ACM</title>
 <short>Commun. ACM</short>
 <publisher>ACM</publisher>
 <address>New York</address>
 <issn type="print">0001-0782</issn>
 <issn type="electronic">1557-7317</issn>
 <url>https://cacm.acm.org/</url>
 <volume>
 ...
 </volume>
 <volume>
 ...
 </volume>
 ...
 </journal>

Journal key

To allow for the correct indexing of a submitted journal volumes, it is helpful if the key of the journal is given enclosed in ‹key› tags (see How to find the key of a person, a publication, or a stream). At most one such ‹key› element must be given in a ‹journal› element. If the key of a journal is unknown, or the journal is new to dblp, the ‹key› element may be omitted.

Journal title

The title of the journal should be given enclosed in ‹title› tags. Each valid journal submission has to include exactly one ‹title› element that may not be omitted. Please use the non-abbreviated title of the journal as given on the cover page.

Short title

If an abbreviated (ISO4) short title is commonly used for this journal, it may be given in ‹short› tags. If no short title is known, then the ‹short› element may be omitted.

Publisher

The publisher of the journal should be given enclosed in ‹publisher› tags. If the publisher is unknown, then the ‹publisher› element may be omitted.

Publisher's address

In addition, the publisher's address should be given enclosed in ‹address› tags. Please use the format "City, State/Province (if applicable), Country". If the publisher's address is unknown, then the ‹address› element may be omitted.

ISSN

Any available ISSN [3] of the journal can be given enclosed in ‹issn› tags. Sometimes, a journal has multiple ISSN for different versions of the publication, such as print and electronic editions. If multiple ISSN are known, a new ‹issn› element can be given for each individual number. If the publication type of an ISSN is known, it can be specified using the optional attribute type, e.g.:

<issn type="electronic">1557-7317</issn>

URL of the journal

If this journal has a website, its URL [5] may be given enclosed in ‹url› tags. If no URL is known, then this element may be omitted.

Journal volumes

 <volume>
 <number>50</number>
 <issue>
 ...
 </issue>
 <issue>
 ...
 </issue>
 ...
 </volume>

A ‹journal› element may contain any number of ‹volume› tags. Each ‹volume› represents a different journal volume. However, to keep the files simple, it might be a good idea to submit only a single journal volume per file. Each ‹volume› element must contain the following child elements:

• Volume number. The number of the volume is given enclosed in ‹number› tags. Each valid ‹volume› element has to include exactly one ‹number› element.
• Volume issues. If the journal volume does not differentiate between issues (or is published as a single issue), please use a single ‹issue› element. Otherwise, provide one ‹issue› element per issue of the volume. The child elements of an ‹issue› element as discussed in the next section .

Volume issues

 <issue>
 <number>1</number>
 <month>January</month>
 <year>2007</year>
 <toc>
 ...
 </toc>
 </issue>

Each ‹issue› element may have the following child elements:

• Issue number. The number of the issue is provided enclosed in ‹number› tags. Please provide only the number of the issue without the number of the volume. So the issue "50(1)" of a journal should give ‹number›50‹/number› in the ‹volume› element, and ‹number›1‹/number› in the ‹issue› element. If the journal does not differentiate between issues (or has no issue numbering), this ‹number› element may be omitted. Please note that ‹number› element of the ‹volume› element may not be omitted, even if a number is provided for each issue.
• Month of publication. If the month the journal issue is published is known, please provide the month enclosed in ‹month› tags. Please use the non-abbreviated name of the month, not the number. If the month of publication is unknown, then the ‹month› element may be omitted.
• Year of publication. The year the journal issue is published is given enclosed in ‹year› tags. Each valid journal submission has to include exactly one ‹year› element per ‹issue› element.
• Table of contents. The table of contents of an issue is provided as a in a single ‹toc› element within the ‹issue› element. Each valid dblp submission has to provide exactly one ‹toc› element per ‹issue› element. The structure of this element is the same for conference proceedings volumes and journal issues. For more information on the table of contents, please refer to the next section.

Table of contents  

 <toc>
 <section>Session 1: Leakage</section>
 <publ>
 ...
 </publ>
 ...
 <section>Session 2: Lattices</section>
 <publ>
 ...
 </publ>
 ...
 <section>Invited Talk</section>
 <publ>
 ...
 </publ>
 ...
 <section>Rump Session</section>
 <text>The slides of the Rump Session are available at:
 https://rump2010.cr.yp.to/</text>
 </toc>

The ‹toc› element represents a traditional table of contents (toc) as found in printed proceeding volumes or journal issues. The toc will be printed in given order on DBLP's website. Hence, the ordering of the toc is of importance.

A ‹toc› element may have any number of the following kind of child elements: section headings, publication records, and multi-purpose text fields. The details of these child elements are addressed below. Please provide these elements in the same ordering as they are given in the printed edition of this volume.

Section headings

The toc may be structured using section headings. Section headings are used for many different reasons, e.g., to provide the topics of conference tracks or sessions, to distinguish paper presentations from poster sessions, or to provide the sections of a journal issue. The use of section headings is optional, but you are welcome to provide them since they greatly enhance the value of a toc.

In the case of conference proceedings, section headings may be provided in hierarchical levels. Headings on the uppermost level are given enclosed in ‹section› tags. If necessary, headings on lower levels may be given enclosed in ‹subsection›, ‹subsubsection›, or even ‹subsubsubsection› tags, e.g.:

<section>Top level</section>
<subsection>Second level</subsection>
<subsubsection>Third level</subsubsection>
<subsubsubsection>Bottom level</subsubsubsection>

In the case of journal issues, section headings usually describe the (non-hierarchical) sections of a journal. Hence, in this case DBLP will not distinguish between different levels of section headings. While it is syntactically possible to use ‹subsubsection› or even ‹subsubsubsection› tags in a journal issue toc, all section headings will be interpreted to be on the same level as a ‹section› element.

Text fields

Sometimes, additional information has to be given in a toc that is neither a section heading nor a publication record. This might be the case with notes on a special issue of a journal, comments on the previous or following publication in the toc, or a note in place of a withdrawn paper. To this end, place a ‹text› element at the appropriate location in the toc. Enclosed in these ‹text› tags, arbitrary text can be provided.

Publications

 <publ>
 <author>Chris Peikert</author>
 <title>An Efficient and Parallel Gaussian Sampler for Lattices.</title>
 <pages>80-97</pages>
 <doi>10.1007/978-3-642-14623-7_5</doi>
 </publ>

For each paper of the proceedings volume or journal issue, details on this paper has to be given enclosed in ‹publ› tags. A ‹publ› element has the following child elements:

• Author(s). The names of the authors of this paper should be given in ‹author› tags. In case of multiple authors, a new ‹author› element has to be used for each individual author, e.g.:

  <author>Ronald L. Rivest</author>
  <author>Adi Shamir</author>
  <author>Leonard M. Adleman</author>
  

  When doing so, please preserve ordering of the authors as given in printed edition of this paper. Note that in the rare occasion that there is no author associated with this paper, the ‹author› element may be omitted. Please use this option only if it is really applicable.
  Matching a given name with the correct dblp person record is an important issue. If the author is already known to dblp, please provide the name as it is stored in dblp. If you want to provide information such as the uft-8 representation of the author name, you can give them by using the optional attribute original, e.g.:

  <author original="&#24373;&#30495;&#35488;">Chin-Chen Chang</author>
  

  For more information on names in dblp, please read Why do person names ignore certain unicode characters, How does dblp handle first names, middle names, family names, non-western names, and How to find the key of a person, a publication, or a stream.

• Title of the paper. The title of the paper should be given enclosed in ‹title› tags. Each valid submission file has to include exactly one ‹title› element per ‹publ› element. In dblp, each publication title ends with either a period, question mark, or exclamation point. If no such punctation mark are given at the end of a title, a period is a appended automatically. Titles should use mixed upper/lower case letters, completely capitalised titles are not acceptable.
• Number of the paper. If the proceedings volume or the journal issue uses a consecutive numbering of its papers, the page number may be given enclosed in ‹number› tags. If no such numbering scheme is used, the ‹number› element may be omitted.
• Pages. The page numbers of the paper should be given enclosed in ‹pages› tags. Please give a single page number (in case of one-sided papers) or a "fromPage-toPage" range of numbers, e.g., "5" or "10-17". If the paper is separated over several consecutive page ranges, please give all of them separated by comma, e.g., "3, 21-24". Please avoid using unspecific notations like "17f." or "42ff." If necessary, page numbers may also be given as roman numerals or alphanumeric entries, e.g., "i-xxi, 1-634". If no page numbering is used for this paper, the \tag{pages} element may be omitted.

• DOI. dblp aims to provide hyperlinks to the electronic editions for all of its listed papers. Unfortunately, a URL is a non-permanent references to a resources they may become unavailable under the given address quite quickly. Thus, dblp prefers to store DOI [1] information as a more persistent link to the electronic edition of a paper. Whenever a DOI is available, please provide the DOI enclosed in ‹doi› tags. If a certain DOI proxy server is preferred with this document, it may be specified using the optional proxy attribute, e.g.:

  <doi proxy="https://doi.acm.org/">10.1145/1536414.1536440</doi>

  
  

• URL of the electronic edition. Whenever possible DBLP uses the DOI to provide a link to the electronic edition of a paper. Only if no DOI is available, a URL \cite{url} pointing to the document may be given enclosed in ‹ee› tags, e.g.:

  <ee>https://conference.itcs.tsinghua.edu.cn/ICS2010/content/papers/5.html</ee>

  Ideally, this URL should point to a page on the publisher's or the conference's official website, dedicated solely to the paper at hand. Such as a page usually states the abstract of the paper and provides a download link for the electronic edition (where access might be restricted to subscribers only). If such a page is not available, the URL directly linking to the PDF file of the paper might be given.
  Please don't provide links to electronic resources on the author's personal websites. Such links are almost impossible to maintain and, thus, won't be included to dblp. Also, do not provide links to preliminary versions or extended versions of the paper, such as full papers stored on preprint servers. The linked document should be identical to the document that has been published in the proceedings volume or journal issue.

References 

[1] International DOI Foundation, Inc., The DOI Handbook. Edition 4.4.1, doi:10.1000/186, 2006.
[2] International Organization for Standardization, Information and documentation -International standard book number (ISBN). ISO 2108:2005.
[3] International Organization for Standardization, Information and documentation - International standard serial number (ISSN). ISO 3297:2007.
[4] International Organization for Standardization, Information technology 8-bit single-byte coded graphic character sets. Part 1: Latin alphabet No. 1. ISO/IEC 8859-1:1998.
[5] T. Berners-Lee, L. Masinter, M. McCahill (editors), Uniform Resource Locators (URL). IETF, RFC 1738, December 1994.
[6] F. Yergeau, UTF-8, a transformation format of ISO 10646. IETF, RFC 2279, November 2003.
[7] W3C, Extensible Markup Language (XML) 1.0 W3C Recommendation. Fifth edition, 2008.

Attachments

• example.bht (1 kB)
• journal-example.xml (1 kB)
• proceedings-example.xml (1 kB)
• dblpsubmission.dtd (1 kB)
• dblpsubmission.xsd (6 kB)
• dblpsubmission.xsl (5 kB)

manage site settings

To protect your privacy, all features that rely on external API calls from your browser are turned off by default. You need to opt-in for them to become active. All settings here will be stored as cookies with your web browser. For more information see our F.A.Q.

Unpaywalled article links

Add open access links from to the list of external document links (if available).

load links from unpaywall.org

Privacy notice: By enabling the option above, your browser will contact the API of unpaywall.org to load hyperlinks to open access articles. Although we do not have any reason to believe that your call will be tracked, we do not have any control over how the remote server uses your data. So please proceed with care and consider checking the Unpaywall privacy policy.

Archived links via Wayback Machine

For web page which are no longer available, try to retrieve content from the of the Internet Archive (if available).

load content from archive.org

Privacy notice: By enabling the option above, your browser will contact the API of archive.org to check for archived content of web pages that are no longer available. Although we do not have any reason to believe that your call will be tracked, we do not have any control over how the remote server uses your data. So please proceed with care and consider checking the Internet Archive privacy policy.

Reference lists

Add a list of references from , , and to record detail pages.

load references from crossref.org and opencitations.net

Privacy notice: By enabling the option above, your browser will contact the APIs of crossref.org, opencitations.net, and semanticscholar.org to load article reference information. Although we do not have any reason to believe that your call will be tracked, we do not have any control over how the remote server uses your data. So please proceed with care and consider checking the Crossref privacy policy and the OpenCitations privacy policy, as well as the AI2 Privacy Policy covering Semantic Scholar.

Citation data

Add a list of citing articles from and to record detail pages.

load citations from opencitations.net

Privacy notice: By enabling the option above, your browser will contact the API of opencitations.net and semanticscholar.org to load citation information. Although we do not have any reason to believe that your call will be tracked, we do not have any control over how the remote server uses your data. So please proceed with care and consider checking the OpenCitations privacy policy as well as the AI2 Privacy Policy covering Semantic Scholar.

OpenAlex data

Load additional information about publications from .

load data from openalex.org

Privacy notice: By enabling the option above, your browser will contact the API of openalex.org to load additional information. Although we do not have any reason to believe that your call will be tracked, we do not have any control over how the remote server uses your data. So please proceed with care and consider checking the information given by OpenAlex.

last updated on 2024-12-05 20:51 CET by the dblp team

 all metadata released as open data under CC0 1.0 license

see also: Terms of Use | Privacy Policy | Imprint

dblp was originally created in 1993 at:

 

since 2018, dblp has been operated and maintained by:

 

the dblp computer science bibliography is funded and supported by: