DC SRAP meeting 13
https://github.com/dcmi/dc-srap/blob/main/meetings/2022-04-19.srap_meeting_13.md
Time: 2022-04-19, 15.00-16.00 CEST (13:00-14:00 UTC)
Place: Zoom, https://helsinki.zoom.us/j/67810295086?pwd=NmJXWGNUZkhJeitSakZ2MEVlRm0yZz09
Attendees: Osma (chair), Tom, Freddy, Alasdair
Regrets: Karen
-
Opening of the meeting
-
Appointment of the minutes taker (Osma will act as the chair)
- Tom volunteers.
- Approval of the agenda
- Approved (no objections).
- Minutes of the previous meeting (2022-04-05)
See https://github.com/dcmi/dc-srap/blob/main/meetings/2022-04-05.srap_meeting_12.md
- Approved.
- SRAP date subproperties
See #20
See current definitions in the document https://github.com/dcmi/dc-srap/blob/main/terms/date_subproperties.md and in particular Juha’s recent changes based on the discussion in the previous meeting: https://github.com/dcmi/dc-srap/compare/bc372ffccf036336210a17ad4fc164a6086456af...8c94f550cff1eee1844021b8f3dd8df2a6597690
-
Osma presents the diff (above).
-
Alasdair: Manuscript the same as Draft?
-
Osma: Manuscript is something submitted. Sometimes, today, these are the same. A bit nervous about distinction between "submitted" and "received" - a question of perspective. In this case, POV of publisher.
-
Alasdair: We definitely need only one date. Documents could be submitted in more than once place.
-
Osma: In general, repositories will record date received or uploaded. In general, definitions are getting better, if not perfect. So I would be happy to include in draft for public comment.
-
Tom: Properties can all be consolidated into one document for public comment.
AGREED: Okay to consider these, for now, good enough for public comment, should put on agenda for next meeting to ensure that others (who could not attend today) agree.
- Affiliation information
Juha (in notes): The example relies in part on the idea of using XML attributes to express PIDS in DC, as discussed in the PIDS in DC session in Porto 2018. However, since the element name id is problematic, I've used pid instead.
See #3
There is now an example (by Osma) of expressing affiliation information in XML: https://github.com/dcmi/dc-srap/blob/main/profile/affiliation-example.xml
-
Osma: This example for a paper from 20 years ago with now-obsolete affiliations. Here: elements and sub-elements. Names are in text, and identifies are in pid attribute. Discussed four years ago in Porto - this follows the basic idea.
-
Alasdair: We cannot just use whitespace with the 'id' attribute (for multiple PIDs), but if we define a new attribute, how will people know what it is?
-
Osma: Colleague recently said there are three ways to express DC in XML.
-
Alasdair: What potential hurdles with rollout? We are asking people to make a small authority-type record. Will that cause problems with the systems that use it?
-
Osma: Not quite agree. This is not like an authority record because it is a snapshot - affiliations as shown in the paper at hand. I do not see how else to do this, besides using 'creator', without creating new properties.
-
Freddy: Authors that have different identifiers.
-
Osma: We can make some recommendations, but basically any ID. Natural to pick Orcids, which are being used more frequently. In Porto, most sensible option was to allow multiple IDs.
-
Tom: Could be awkward to have dcterms:agent when there is already dcterms:Agent (a class).
-
Osma: Also thinking of foaf:focus...? Maybe these (in example) should be wrapped with AffiliatedAgent. Had intended to do that (changes example in GH issue). Each creator is instance of AffiliatedAuthor.
-
Fredy: How to know principle author - possible to have label? Essential to know.
-
Alasdair: Cannot solve the problem of how many "primary" and "secondary".
-
Tom: Some syntaxes (JSON-LD, XML?) preserve order; RDF only by adding constructs.
-
Freddy: Common in Latin American repositories that order of authors listed not preserved - everyone a creator.
-
Osma: As Freddy saying, may not be clear "principle author". "Corresponding author" could be captured in data... Bottom line: Question of principle author could be separate issue. MARC allows only one author in $100, everyone else in $700s. DC does not have notion of primary author.
ACTION: Osma to create Markdown file with these classes and properties.
ACTION: Alasdair to contact people interested in working on the general specification for PIDs.
- Drafting the SRAP specification in Markdown
This was discussed in the previous meeting and the consensus was that we should start drafting the finished parts of SRAP in Markdown format.
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
DECISION: Continue producing snippets in Markdown that can gradually be assembled into something that looks like a more finished draft.
-
Any other business
-
Next meeting
DECISION: Osma to propose to the list that next meeting (May 3) be held one hour earlier. (Karen will be in Europe.) Plan B: One hour later.
- Closure of the meeting