Skip to content

Latest commit

 

History

History
112 lines (63 loc) · 4.08 KB

2022-10-11.srap_meeting_18.md

File metadata and controls

112 lines (63 loc) · 4.08 KB

DC SRAP meeting 18

Time: 2022-10-11, 14:00-16:00 UTC, 17.00-19.00 CEST
Place: Zoom, https://helsinki.zoom.us/j/66651804340?pwd=ZnpWNzBOYlIraTE3SnNzeEd4ZjYyUT09

Present: Juha, Osma, Tom, Alasdair, Karen, Jan

  1. Opening of the meeting

Juha opened the meeting

  1. Appointment of the minutes taker (Juha will act as the chair)

Alasdair to take minutes

  1. Approval of the agenda

  2. Minutes of the previous meeting (2022-09-27, number 17)

See https://github.com/dcmi/dc-srap/edit/main/meetings/2022-09-27_srap_meeting_17.md

Juha: profile now marked as draft; non-resolving links to DC Terms marked with asterisk

  1. DC TAP profile (Karen)

See the spreadsheet, available at https://docs.google.com/spreadsheets/d/1AzqiaLRRdH5qXkOI-mEwuT9gln9HZhrWhukeDfnP2ug/edit#gid=1013040629

Karen: has tabs for ’plain’ profile and enhanced – not official; iri/literal value type may vary Enhnaced tab includes shapes for person and organisation agents including name and identifier Example of using SRAP in a particular application Shapes for person/organisation have class - schema.org/person

Osma: value in ’person’ or ’organisaion’ – ’instance of’ better than iri or literal DC profile needs to stay with flat structure; does not differentiate between person and organisation Class is ’agent’

Karen: Many users will need greater specificity. What do we want SRAP to be?

Juha: iri can accomodate any character – can cause problems Advise use of ORCID/ISNI identifiers

Alasdair: include identifiers from national libraries, e.g LC, DNB, BNF

Osma: change from iri to class, e.g. ’agent’; move to higher level

Karen: could drop valueNodeType – record class as valueConstraint

Tom: add column for valueClass

Osma: work on profile to make it more suitable for TAP; propose class over iri

  1. Roles in SRAP

In the 17th meeting, we agreed on using MARC relators:

“In the profile, say that any MARC relator properties can be used and provide examples of common properties.”

Juha has made a pull request for a profile version which has a separate table for the following roles:

Current role-specific terms/properties in SRAP are the following: • Degree supervisor http://id.loc.gov/vocabulary/relators/dgs • Editor https://id.loc.gov/vocabulary/relators/edt • Funder https://id.loc.gov/vocabulary/relators/fnd • Opponent http://id.loc.gov/vocabulary/relators/opn • Praeses http://id.loc.gov/vocabulary/relators/opn

Only Editor is a sub-property of Contributor.

Karen: Does SRAPO say ‘these are’ or ‘are most common’?

Tom: Say that these are suggested. Use relators from other vocabularies?

Juha: Libraries would use different URIs for the same thing; LC relators are well known

Karen: make these ‘recommended’ rather than ‘required’

Tom: Strong recommendation

Jan: DataCite uses a controlled list; ‘sponsor’ has a different meaning to ‘funder’, for example

Juha: Make a recommendation, but allow flexibility

Osma: RDA is expressed as RDF and contains wide range of properties

Juha: Recommend LC but actual use up to the implementer

Karen: Use from an identified list

Juha: Adopt some roles into DC Terms?

Karen: Usage Board takes in what is required; same level of detail for all DC Terms. Other profiles have developed and submitted for addition to DC Terms, using approved methodology. Additions will need to follow the rules.

Juha: Adding to DC Terms would be as distraction as so specialized. Keep separate in current SRAP draft. not possible to add so many. Helpful to say that existing lists of controlled terms for roles can be used.

Osma: Any property from any list

Karen: Property vs role value for contributors

Juha: Only some LC realtors are sub-classes of DC Contributor

Recommendation of using LC relators, with examples of how to express them Edit to SRAP draft – use controlled list such as LC relators

Juha: Don’t add more roles to profile – can be done locally

  1. Any other business

Juha: Lost / missing – lost implies can be found; suggest permanentLoss for resource that will not be found again

  1. Meetings during Autumn / Winter 2022

  2. Closure of the meeting