- Time: 2022-05-03, 14.00-15.00 CEST (12:00-13:00 UTC)
- Place: Zoom, https://helsinki.zoom.us/j/67810295086?pwd=NmJXWGNUZkhJeitSakZ2MEVlRm0yZz09
- Present: Juha (chair), Osma, Tom, Jan, Alasdair, Nishad
Juha opened the meeting at 14:05 CEST
Osma selected as the minutes taker.
Agenda approved.
Minutes were published at https://github.com/dcmi/dc-srap/blob/main/meetings/2022-04-19.srap_meeting_13.md
Approved the following list of statuses:
- public draft
- submitted manuscript
- preprint
- postprint
- publication
- updated publication
See #11
Tom: What is an update?
Juha: It's an updated publication - something has been publicly available but later changed.
Tom: Could it be called "updated publication" then?
Juha: Yes, we can change that.
Juha: Can we approve this as final (for now) so we can move into other parts of the profile?
No objections, status list approved. This will be a part of the SRAP specification that will eventually be sent to the Usage Board.
Juha: These should not be set in stone - if there are good reasons to change, the discussion can be reopened.
See #20
Date subproperties and their definitions in:
https://github.com/dcmi/dc-srap/blob/main/terms/date_subproperties.md
were approved by the attendees of the 13th meeting of the WG. Is this good enough for public review or do we still need to change something? (all)
Osma: What about dateAccessioned? This seems to be automatically generated by DSpace repositories, meaning the time when the document was uploaded. A bit lower level, technical timestamp than these.
Juha: We can return to this later; I am not fundamentally opposed if there is a good case for it.
Jan: dateAccessioned seems more like administrative metadata of the repository, more than about the resource itself.
Alasdair: A date in the repository more than relevant for resource itself.
Juha: Technical, administrative. If we want to add it, need to think how it relates to the statuses.
Osma: Maybe better not to include.
Juha: Do we need to change dateUpdated as well?
Tom: Could it be dateUpdatedAsPublication? This would follow the same pattern as the others. dateUpdated is too general.
Juha: We can provide guidance. For instance, dateMissing could relate to any status whereas dateRetracted only involves publications or updated publications. Rename to dateRetractedAsPublication.
Jan: Dates are already very specific. Do we want them to be more generalizable for DCMI? These are now specific to libraries and academic publication processes in journals.
Alasdair: For dateUpdated, if we don't make it specific, we could run the risk that people don't read the scope notes and use it improperly.
Juha: Should we provide essential information in the name of the property or just in the description? We are toeing a fine line here. dateUpdatedAsPublication is a useful clarification - we don't want people to use it for when a preprint is turned into a postprint.
Tom: Resources will accumulate many dates, which gives a record of status changes. If we used less specific, more generic properties, that would need more data modelling.
Juha: It's important to keep a record so we can determine who came up with an idea first. Other formats are not doing this yet.
Alasdair: Would we allow multiple similar dates for a series of updated?
Juha: That might require creating a new resource. Minor updates can be done in the same resource/record, but major updates would require a new one.
Juha: I think this is a reasonable starting point. Are we ready to approve this set of date properties?
Tom: Has Karen given any comments?
Juha: She has commented in the past, I've considered them in the current proposal.
Approved the following date subproperties:
- dateAvailableAsPublicDraft
- dateReceivedAsManuscript
- dateSubmittedAsPreprint
- dateSubmittedAsPostprint
- dateAccepted
- dateAheadOfPrint
- datePublished
- dateUpdatedAsPublication
- dateRetractedAsPublication
- dateMissing
- dateLost
See #3
Description of the new class and properties should be written in a Markdown snippet (Osma).
There is an example (by Osma) of expressing affiliation information in XML: https://github.com/dcmi/dc-srap/blob/main/profile/affiliation-example.xml
Osma: Have not written up the Markdown snippets yet - next meeting. (Shows XML example: paper 20 years ago with three authors and affiliations at the time - very simple record with data and DC terms - title and three authors expressed with dct:creator. In all cases, value of creator element is not just a name, but element "Affiliated Agent". PID attribute used to express identifier - could be ORCIDs, Wikidata IDs - any sort of semi-persistent identifier. Structured way to express information given on the first page of the paper. Question whether it is appropriate to use the attribute pid= in this way. Agent and Affiliation as properties of creator. Attribute id= is reserved in XML - so cannot use - this was a bug in what we discussed in Porto - Opened Issue 17 in 'dcmi/pids_in_dc' repo. With id= can only have one value - and value must be unique within the context of the XML document.)
Juha: Problem with PID: "persistent identifier" should not be just an ordinary URL. Would use that only for an ISNI or ORCID.
Osma: I can edit the example to put in real ORCIDs or other PIDs.
Alasdair: We could take quick jump up to my agenda point - been contacting people who were interested. Alasdair, Osma, Scott, John on a call? My question: If we do not use id= (good reasons not to).
Tom: Could publish as a DCMI Note.
Juha: Can't be part of SRAP, it's more generic. SRAP can use it if it's published.
Alasdair: There are different use cases for PIDs, including also subjects.
Juha: Similar function as MARC subfield zero.
Alasdair: If we had published best practice guidelines, we could explain how to use this attribute.
Tom: If you introduce a new XML attribute, is it good practice to introduce it with a namespace? If it required a namespace, I guess it wouldn't be that much extra work. Important to follow established conventions in the XML world.
Juha: So we will have a recommendation on PIDs in DC and we can offload this to a group of other people.
There is already a crude Markdown version of the original SRAP draft specification (2021-01-08): https://github.com/dcmi/dc-srap/blob/main/profile/srap_proposal_20210108.md
Snippets created after the 13th meeting (if any).
Juha: We could take up new element such as grants. Will discuss with Osma and Tom.
Scheduled to take place 2022-05-17, 13:00-14:00 UTC
Juha closed the meeting.