Skip to content

Known Issues

Marcel R. Ackermann edited this page Mar 11, 2025 · 8 revisions

Known limitations of the current dblp RDF schema

If you happen to find a limitation that is not listed here but that you would like to see addressed, please let us know via dblp(at)dagstuhl.de. Thank you very much!

  • currently no entity modelling is implemented (but planned) for

    • affiliations
    • publishers
    • conference/workshop events ('the actual meeting' as opposed to 'the proceedings')
    • table of contents (i.e., volumes and issues)
  • no modelling is planned (since no such data is available in dblp) for:

    • first/last/middle/etc name part breakdown
    • person bio data (such as birth dates, nationality, gender, etc); we link to wikidata.org, so such information might be available there
    • email addresses or contact information beside academic homepages
    • language of dblp:title or full-texts, etc
    • distinction between sub-types of dblp:Inproceedings, like poster or full-paper
    • distinction between sub-types of dblp:Article, like preface or book review
    • distinction between sub-types of dblp:Book, like textbook, phd thesis, habilitation, etc
    • no author/editor information is available for dblp:Withdrawn items
  • no cites/cited-by links will be available in dblp; such information can be obtained from OpenCitations.net using the dblp:omid links we provide

  • dblp:monthOfPublication information is only very, very rarely available

  • some metadata of dblp:Inproceedings and dblp:Incollection, like ISBN of containing book, containing series, publisher, etc is currently not available at publication level (needs to be accessed via dblp:publishedAsPartOf)

  • some metadata of dblp:Article like ISSN is currently not available at publication level (needs to be accessed via dblp:publishedInStream)

  • in the full dblp RDF dump, a number of implicit properties are omitted due to technical limitations of the dump file creation process, as well as for space efficiency; those properties can still be inferred from the contained data and created locally if necessary:

    • D dblp:createdBy A implies A dblp:creatorOf D
    • D dblp:authoredBy A implies A dblp:authorOf D
    • D dblp:editedBy A implies A dblp:editorOf D
    • D dblp:createdBy A and D dblp:createdBy B and A != B implies A dblp:coCreatorWith B
    • D dblp:authoredBy A and D dblp:authoredBy B and A != B implies A dblp:coAuthorWith B
    • D dblp:editedBy A and D dblp:editedBy B and A != B implies A dblp:coEditorWith B

Known issues of the dblp SPARQL endpoint

The public dblp SPARQL endpoint is powered by the QLever SPARQL engine. The engine itself has an issue tracker located at their Github repository.

Clone this wiki locally