Skip to content

Latest commit

 

History

History
121 lines (56 loc) · 5.66 KB

2023-06-20.srap_meeting_31.md

File metadata and controls

121 lines (56 loc) · 5.66 KB

DC SRAP meeting 31

Time: 2023-06-20, 15:00-16:00 UTC Place: Zoom, https://helsinki.zoom.us/j/67426809443?pwd=QmJEdjY0dXFkMC9VWjNnSGx6cFlRdz09

  1. Opening of the meeting

  2. Appointment of the minutes taker - Karen

  3. Approval of the agenda

  4. Minutes of previous meeting

2023-05-09, number 30. Alasdair has submitted a draft.

  1. ISO TC 46/SC 4/WG 16 Dublin Core (Juha)

TC 46/SC 4 decided in its plenary meeting to disband WG 16, as suggested by the working group itself. The group will be reactivated once DCMI has completed SRAP, except if DCMI decides to use Fast track process, via which standards of Category A liaison organizations can be approved as ISO standards unchanged.

However, my recommendation is to avoid using Fast track, and ask TC 46/SC 4 to reactivate WG 16, which will then initiate revision of ISO 15836-2. Since SRAP is at this point a mature specification which has been approved by DCMI, the working group may suggest that the working draft, if accepted becomes a Draft International Standard (DIS).

Using the normal ISO process will allow both WG 16 and TC 46/SC 4 P members to provide feedback, with which DCMI may be able to make improvements to SRAP, in the same way as comments from WG 16 were used to adjust DCMIMT. Fast track process would not allow this kind of cooperation between ISO and DCMI. Minutes: ISO group has been disbanded

  1. Enumeration

GitHub issue: #28

2023-05-22 Jan Ashton sent to the list a summary of the draft DataCite enumeration/host item approach.

“ContainerInformation” property can be used to describe e.g. books containing book chapters and journal issues containing articles. Its sub-properties include title, creator, date, containerIdentifier, containerIdentifierScheme, number, resourceTypeGeneral.

“SeriesInformation” property can be used to describe e.g. journal for a journal issue or journal article. It has sub-properties positionInSeries, volume, issue, number.

Extent (page numbers), first page and last page can be used with both properties.

To be discussed:

Can we / should we use the draft DataCite specification as the starting point? If not, is there another specification we should rely on?

Should we include both ContainerInformation (to accommodate component parts of monographs such as book chapters) and SeriesInformation?

Minutes: DataCite container information, and series information

Container: extent, firstpage lastpage position (chapter number) identifier title creator date version, position in series, number volume issue, series title See crossref and NLM DTD

Osma: this is a flat list; it could be modeled as two resources, and title and creator could be from Dublin Core Mods can have nested related items

Osma: if flat, we need more properties; if nested, then we need fewer elements; makes sense to use nesting

Karen: nesting is better for sharing, because different groups will have different views

Osma: separate records is more like library cataloging, in our catalog

Karen: DC partOf?

Osma: (Showing project using Dublin Core) Data from a number of different sources and different document types.

Karen: DC doesn’t have resource type

Jan: this is a controlled list in DataCite

Osma: how many levels do you need?

Juha: depends on how deep you want to go; but always the same host record level. In practice only two levels have been used; archives use different numbers of levels; if nested don’t need to limit number of levels; we are in agreement that we go with nested, hierarchical levels

Osma: gives example, using DC and hasPart/isPartOf; much of container (journal) is covered, except for beginDate, endDate; document level needs series number, volume, extent, DOI, isbn.

Karen: can dc:identifier work for isbn, issn, doi, etc. Many are URNs not URIs, but still are identifiers; if people have local identifiers they have to make those clear

Osma: need extent (number of pages) and page range

Jan: not number is series but also issue number; maybe we don’t need separate numbers

Alastair: there can be lots of different levels each with numbers

Osma: Conference papers need conference info as well

Juha: shouldn’t get too detailed;

Alastair: using pre-3R in cataloging; don’t think we can be too brief on this; but if conference is online, may not be needed; conference proceedings are similar to books and book chapters; difference between published and online presentation

Juha: for online conferences, the conference is the container. What is the link in hasPart?

Osma: we don’t need to define what the linking identifiers are; that’s a system question

Make Osma’s draft a comment in issue #28; add these to the DCTAP table

Karen: try to create table with different bibliographic models; include MARC if possible

  1. Related dataset

GitHub issue: #9

On a previous call (30), we tried to find an alternative name for this property. The name “relatedDataset” does not feel right, because it encodes the type of the object (Dataset) into the property name. Alas, we were not able to find a better name.

However, majority of the attendees felt that there is a need for a SRAP property with which datasets and other resources can be linked to the described resource. And dataset is often correct, since publishing e.g., an article and data it is based on together is becoming a normal practice.

Suggestion: use relatedDataset for now since although not perfect, it is often correct. It is not possible to create a property for each type of related resource, and a more abstract name (relatedData) was turned down as too vague.

  1. Any other business

Tentatively: next meeting will be July 25

  1. Closure of the meeting