Skip to main content

Notice

We are in the process of rolling out a soft launch of the RDA website, which includes a new member platform. Existing RDA members PLEASE REACTIVATE YOUR ACCOUNT using this link: https://rda-login.wicketcloud.com/users/confirmation. Visitors may encounter functionality issues with group pages, navigation, missing content, broken links, etc. As you explore the new site, please provide your feedback using the UserSnap tool on the bottom right corner of each page. Thank you for your understanding and support as we work through all issues as quickly as possible. Stay updated about upcoming features and functionalities: https://www.rd-alliance.org/rda-web-platform-upcoming-features-and-functionalities/

#129494

Good morning Hugh,

thank you again!

One thing I would like to stress in this discussion is the purpose of references, which should identify and point to some source or resource. IMHO references are not intended to fully and thoroughly describe the object it is identifying, as this is either done with an imprint (or other means) in a printed resource or a landing page of a digital resource.

The Dublin Core’s DCMI Type and BibLaTeX’s Entry Types are two different pair of shoes with very different backgrounds and terminology. While the DCMI Type vocabulary was already developed with digital data collections and different resource types in mind, the Entry Types of BibLaTeX originate in bibtex which itself was first released in 1985. bibtex and biblatex were developed having printed contributions in mind and therefore the Entry Types concentrate on such, e.g. @collection is defined as:

A single-volume collection with multiple, self-contained contributions by distinctauthors which have their own title. The work as a whole has no overall author but itwill usually have an editor.

From this definition, it becomes clear that it is not possible to just use that type for electronic data collections, especially if having in mind that a user might include various different kinds of references in a bibliography. The best fit is @dataset, which was introduced as a fully supported Entry Type in BibLaTeX in 2019. It is quite vaguely defined as

A data set or a similar collection of (mostly) raw data.

For the purposes of including a reference to a data collection, I think this vague definition is fine. I think introducing corresponding biblatex Entry Types for each of the DCMI Types should be avoided to (1) prevent the list of Entry Types from exploding, (2) avoid dealing with disambiguation in defining Entry Types, (3) keep the adoption barrier low. Adoption is key: it does not suffice to have a proper Entry Type, but also, after properly defining the Entry Type, respective citation styles (e.g. with the Citation Style Language (CSL)) should be available for convenient use.

What I am trying to achieve is (a) provide a convenient way for user’s of our repository to save a reference to a data collection to their bibliography, and (b) do this in a way that it can be widely used without much tinkering like installing proper packages etc. This is why I thought that shaping and expanding the @dataset Entry Type (and the necessary and optional Entry Fields) directly for one of the next releases of BibLaTeX (see issue on GitHub) might be the best way. (Another task would be to advocate for proper data referencing in the respective communities and try to influence citation guidelines.)

To wrap up a bit here are the key points that came up in this discussion, which I will suggest over there:
* way to reference the components of the aggregate unit (i.e. part of a data set)
* get an Entry Field to allow to indicate the type of @dataset (e.g. with terms from DCMI Type)
* have an Entry Field to allow storing a “query”

By the way: BibLaTeX has an Entry Type @software, but it is treated as an alias of @misc. and it could also be worked and expanded on, if wanted.

Best
Martina