I. Documentation

I.A. Spreadsheet

I.A.1. "Delete" status

Reasons for not mapping a row/justifications for recording "Delete" should go in "Notes--Uncategorized" column, not in "Justification for Mapping" column. 2022-03-23

I.A.2. Transformation notes

Add transformation notes whenever possible. 2022-03-23

I.A.3. Comments

Do not comment on spreadsheets in Google Sheets. Comments, discussions, and issues should be located and tracked in GitHub. 2022-05-18

I.A.4. Syntax

I.A.4.a. Condition Layering

    I.A.4.a.i. Multiple values for the same MARC subfield condition with OR relationships should be recorded in the same cell, with | as delimiter. 2022-02-23

    I.A.4.a.ii. Independent conditions get separate rows in the spreadsheet. Layered conditions are in multiple columns of the same row. 2022-01-06

    I.A.4.a.iii. New sets of MARCTagCondition/ConditionValue columns may be added as needed to create more layered conditions with AND relationships to one another. 2022-04-06

I.A.4.b. Punctuation differences in label values for conditions should be ignored/treated as the same. For instance, “Based on (work)” and “Based on work” should be treated as the same string. 2022-02-23

I.A.4.c. Updated Instructions to include formatting for MARCTagCondition cells and corresponding value cells. 2022-04-06

I.A.4.d. Added table with prescribed syntax operators. 2022-04-06

I.A.5. Finished Spreadsheets

Mapping Spreadsheets that are finished should move rows with final statuses other than "done" to new sheets in the workbook to reduce redundancy and improve readability. E.g., move deleted rows to a new “Deleted” sheet within the workbook. See issue. 2024-12-04

I.B. Versioning

I.B.1. GitHub Version Control

We will rely on GitHub’s versioning control, and refrain from adding new columns/notes to record different iterations of the mapping spreadsheets over time. 2022-02-16

I.B.2. Draft Versions in Google Sheets

Draft versioning will rely on Google Sheets, with frequent semi-automated pushes to GitHub by Theo. 2022-06-22

I.C. Transformation Disclaimers for Users

I.C.1. rdam:P30103 "has exemplar of manifestation"

I.C.1.a. This mapping and transform mints a distinct rda:Item for each field indicating item-specific data, such as $5, even when they occur with the same values within the same MARC record. This avoids conflating distinct items within the same collections, but runs the risk of minting redundant rda:Item entities and IRIs when only a single item exists. Manual reconciliation after conversion at the institution level is recommended. 2023-05-31

I.C.2. rdam:P30134 "title of manifestation"

I.C.2.a. Inconsistent application of punctuation and MARC subfielding rules create messy data here. The transformation has been written to accommodate a majority of cases. Manual review is suggested where manifestation titles include ISBD punctuation such as " = " or " ; ". 2023-05-31

I.D. MARC21 Fields & Subfields Not Mapped

I.D.1. When we decide to exclude a MARC field or subfield and mark it "not mapped", we ought to provide a reason. This section provides a list of unmapped fields/subfields and justification where not self-explanatory. Undefined or redefined subfields and character positions are excluded. 2023-06-13

I.D.3. $8 "Field link and sequence number"

I.D.3.a. We will not map $8 until a use case is provided. 2022-07-14

I.D.4. 008 "Fixed Length Data Elements" Character Positions

I.D.4.a. 008/05 "Date entered on file" 2023-06-13

I.D.4.b. 008/38 "Modified record" 2023-06-13

I.D.4.c. 008/39 "Cataloging source" 2023-06-13

I.D.4.d. 008/32 BOOKS "Main entry in body of entry" [OBSOLETE] 2023-06-13

I.D.4.e. 008/18 COMPUTER FILES "Frequency" [OBSOLETE] 2023-06-13

I.D.4.f. 008/19 COMPUTER FILES "Regularity" [OBSOLETE] 2023-06-13

I.D.4.g. 008/27 COMPUTER FILES "Type of machine" [OBSOLETE] 2023-06-13

I.D.4.h. 008/20 CONTINUING RESOURCES "ISSN center" [OBSOLETE] 2023-06-13

I.D.4.i. 008/30 CONTINUING RESOURCES "Title page availability" [OBSOLETE] 2023-06-13

I.D.4.j. 008/31 CONTINUING RESOURCES "Index availability" [OBSOLETE] 2023-06-13

I.D.4.k. 008/32 CONTINUING RESOURCES "Cumulative index availability" [OBSOLETE] 2023-06-13

I.D.4.l. 008/34 CONTINUING RESOURCES "Entry convention" 2023-06-13

I.D.4.m. 008/26-27 MAPS "Publisher code" [OBSOLETE] 2023-06-13

I.D.4.n. 008/32 MAPS "Citation indicator" [OBSOLETE] 2023-06-13

I.D.4.o. 008/30 MIXED MATERIALS "Case file indicator" [OBSOLETE] 2023-06-13

I.D.4.p. 008/32 MIXED MATERIALS "Processing status code" [OBSOLETE] 2023-06-13

I.D.4.q. 008/33 MIXED MATERIALS "Collection status code" [OBSOLETE] 2023-06-13

I.D.4.r. 008/34 MIXED MATERIALS "Level of collection control code" [OBSOLETE] 2023-06-13

I.D.4.s. 008/32 MUSIC|VISUAL MATERIALS "Main entry in body of entry" [OBSOLETE] 2023-06-13

I.D.4.t. 008/21 VISUAL MATERIALS "In LC Collection" [OBSOLETE] 2023-06-13

I.D.4.u. 008/23-27 VISUAL MATERIALS "Accompanying matter" [OBSOLETE] 2023-06-13

I.D.5. 245 subfields

I.D.5.a. $d "Designation of section (SE)" [OBSOLETE] 2023-06-13

I.D.5.b. $e "Name of part/section (SE)" [OBSOLETE] 2023-06-13

I.D.6. 871 "Variant corporate name" [OBSOLETE]

Could not find sufficient MARC documentation 2023-06-13

I.D.7. 870 "Variant personal name" [OBSOLETE]

Could not find sufficient MARC documentation 2023-06-13

I.D.8. 381 "Other distinguishing characteristics of work or expression"

No way to determine whether this applies to the work or expression entity. Field not widely used. 2023-06-06

I.D.9. 562 "Copy and version identification note"

Diffuse semantics 2024-02-01

I.D.10 6XX Fields $e and $4

All relationships for all 6XX fields map to ‘subject _____’ 2024-06-26

I.D.11. 085 SYNTHESIZED CLASSIFICATION NUMBER COMPONENTS

This field duplicates the classification number recorded in fields 082 and 083, so it does not need to be transformed. 2024-04-02

I.D.12. 042 "Authentication code"

This is authenticating the MARC record as part of a workflow among specific agencies. Outside of scope of RDA as not treating MARC record as a metadata work that relates to an RDA data set. 2025-01-08

I.D.13. 025 "Overseas Acquisition Number"

These numbers only apply for Library of Congress internal acquisitions. Will not map unless there's clear utility beyond LoC internally. 2025-01-04

I.E. Values Not Mapped

I.E.1. Values not considered useful:

• "Unknown"
• "Other"
• "Not applicable"
• "Not specified"
• "No attempt to code"
• "Not [*]"
• "None of the following" 2023-06-13

I.E.2. Obsolete values

Not mapped unless unique (code not redefined, for instance) and believed to be useful 2023-06-13

II. Mappings

II.A. Redundancy

II.A.1 Write as few conditions as possible.

II.A.2. Map the redundant data, push any duplicate triple issues downstream. 2022-01-26

II.B. 5XX Notes

II.B.1. We will map 500 notes as "has note on manifestation" for now, with status "?". Revisit later. 2022-03-23

I.B.1.a. 535: Note on manifestation: note with boilerplate describing what the field and subfields mean in context of indicators. -Meeting choice, 2023-12-13 See issue discussion and meeting notes

II.B.2. When subfields are collated into one unstructured description, we will separate subfields with a '; ' 2024-07-02

II.B.3 When a field or subfield is private, the field or subfield is reified as a metadata work with category of work "private" 2024-07-23

e.g.

ex:Item1 rdaio:P40164 ex:MetaWork1 [is item described with metadata by]
ex:MetaWork1 rdf:type rdf:statement .
ex:MetaWork1 rdf:subject ex:Item1
ex:MetaWork1 rdf:predicate http://rdaregistry.info/Elements/i/P40026 [has custodial history of item]
ex:MetaWork1 rdf:object "[contents of private field or subfield]" .
ex:MetaWork1 rdawd:P10004 "private" [category of work]

See issue for field 561 for discussion on decision

II.C. $0/$1

II.C.1 $0's and $1's for RDA Entities

II.C.1.a We will use a developed list of approved sources for $0, $1, and $2 values for each RDA entity type to determine whether $1 and $2 values are retained in the mapping and transform (see slides for additional details - “Approved” refers to Approved URI list, which is used alongside URIs in MARC list).

• When $1 is approved: $1 value is used as the entity IRI
• When $1 is unapproved or not present: an IRI is minted for the entity
  • When $1 is present: it is stringified as an identifier for the entity
• When $2 is present: a nomen is minted for the access point with the scheme of nomen from $2
  • When $2 is approved: the access point is authorized (AAP)
  • When $2 is unapproved: the access point is not authorized (AP)
• When $2 is not present: The access point is not authorized (AP) and is a string value with a datatype property 2024-11-13

    II.C.1.a.i. We will not make statements about the IRI in subfield $1 except for adding an access point triple and any identifiers stringified from $0 or $1 values. If the source of the heading is given, the heading object will be a minted nomen; if not, the object will be a literal string. If a nomen is minted, we will make statements about the nomen that include the nomen string and the scheme/source of the nomen. 2024-07-03, 2024-11-06

    II.C.1.a.ii. When the field contains multiple $1 values, we will accept the first approved value provided. 2024-11-06

    II.C.1.a.iii. In phase 1, we will recognize and process $0 values as $1 values for RDA Entities only when they are FAST identifiers that can be transformed into RWO IRIs. 2024-11-27

    II.C.1.a.iv. Unused, unapproved $1 values will be retained as stringified identifiers for the RDA Entity. 2024-11-13

    II.C.1.a.v. How to mint the IRI

• Nomens always use opaque IRIs, i.e. are randomly generated.
• If an approved source is present, the IRI uses the source and access point to mint the IRI for the entity.
• If there is not an approved source, the IRI is an opaque running number.

II.C.2 $0's and $1's for 3XX fields

II.C.2.a We will record an external IRI in a subfield $0 or $1 from a 3XX field as the object of a triple of an attribute property. 2024-07-16

    II.C.2.a.i. We will recognize and use subfield $0 values as IRIs when they contain 'http'. 2024-07-16

See discussion for more details

II.C.3 $0's and $1's for skos:Concepts

Any $1 value is used, and $0 is used if it is a FAST identifier and can be converted or if it is identified as an IRI (containing http). We do not have an approved list for concepts like we do for RDA Entities.

II.D. Properties and IRIs from Outside the RDA Registry

II.D.1. IRIs

II.D.1.a. When an IRI is needed and cannot be found in the RDA Registry, IRIs from other sources may be used. 2022-04-06

II.D.1.b. Prefer the following sources, in this order, for supplying outside IRIs:

    II.D.1.b.i. Library of Congress

    II.D.1.b.ii. MARC21 Vocabularies from Metadata Management Associates, available via Open Metadata Registry

II.D.2. Properties

II.D.2.a. Assigning properties from outside the RDA Registry is out of scope at this time. Assign the next-most-specific appropriate RDA property and record "loss" in the Status column. We will compile these later and send to RSC for advice. 2022-04-06

II.D.2.b. An exception to Decision II.D.2.a has been made with regard to concepts, such as those represented by classification numbers and subject headings. We will follow RDA's lead and use SKOS properties to refer to skos:Concepts in this mapping. 2024-03-06

II.E. Control Fields

II.E.1. Unknown/Other as values

Will not be mapped/recorded. We only want to include "valuable values". 2022-02-02

II.F. Obsolete Fields/Subfields/Character Positions

We will need to check on whether obsolete fields/subfields/character positions are being used in source data ourselves. Since they are obsolete, we will not prioritize this work right now, and will put off mapping obsolete fields/subfields/character positions until at least the end of the PCC RDA BSR/CSR milestones. 2022-06-01

II.G. $6

II.G.1. We will preserve $6 data, even for entities where authorities exist. 2022-07-20

II.G.2. The 880 should be mapped according to the associated field identified in $6. 2022-10-19

II.G.3. Incorrect MARC in 880s

In practice, the regular field associated with the 880 through $6 may not contained the corresponding romanized form of the 880 or vice versa, especially for 520 or 650/655 fields. This is incorrect MARC, and will not be accounted for in the mapping. Libraries with holdings attached to such records should clean up incorrect fields.

Examples:

https://lccn.loc.gov/2021421243

520 ## |6 880-06 |a Detailed summary in vernacular field only.

880 ## |6 520-06/$1 |a "学者的人间情怀"是陈平原的代表作,论及"学术史""走出'五四'""左图右史""述学文体","演说现场","报刊研究"等重要话题,也都点到为止,好在大都日后在专业著作中有所展开.最重要的是,反映了他当时"压在纸背的心情".

OCLC #910728126

650 7藝術社會學. ǂ2 lcstt ǂ0 http://catld.ncl.edu.tw/subject/sh0018327

650 7Art and society. ǂ2 fast ǂ0 (OCoLC)fst00815432

650 7中国书法. ǂ2 local/OSU

650 7Calligraphy, Chinese. ǂ2 fast ǂ0 (OCoLC)fst00844390

651 7中國. ǂ2 lcstt ǂ0 http://catld.ncl.edu.tw/subject/sh0001067

651 7China. ǂ2 fast ǂ0 (OCoLC)fst01206073

655 7歷史. ǂ2 lcstt ǂ0 http://catld.ncl.edu.tw/subject/sh0016956

655 7History. ǂ2 fast ǂ0 (OCoLC)fst01411628

II.G.4. $6 and Minting of new Nomen Entities for literal field values

II.G.4.a. We will mint Nomens where the property range for a regular/880 field maps to either an RDA Entity with a secondary property with a range of Nomen, or when the mapped property's range is simply a Nomen. Where a property lacks a range, we will create literal values only. We will not reify triples with literal values in order to retain equivalence relationships between string values not associated with a Nomen. 2022-10-18

II.G.4.b. Where a Nomen is minted, the MARC 880 and regular field linked by $6 are mapped this way:

[WEMIEntity1] [propertyWRangeNomen1] [Nomen1]

[Nomen1] [hasNomenString](rdand:P80068) ["literal value of regular field"]

[Nomen1] [isEquivalentTo](rdand:P80113) ["literal value of 880"] 2022-10-18

II.G.4.c. Where a Nomen is not minted, the MARC 880 and regular field linked by $6 are mapped this way:

[WemiEntity1] [propertyWORangeNomen] ["literal value of either field"]

2022-10-18

II.G.5.d Script and language of strings cannot be reliably determined from the MARC format in $6, and so are not mapped. 2022-10-18

See 2022-10-05 meeting notes for more notes on this decision

II.H. Access Points

II.H.1 Punctuation

II.H.1.a Internal punctuation provided in the MARC field will be retained in the transformed access point. 2024-06-12

II.H.1.b For now, the code will retain all ending punctuation apart from commas for agent access points. When we take a look at output data from the transform, we will be able to see if there are other punctuation we would like to handle differently. 2024-06-12

II.H.1.c We remove periods from subject headings unless the word/abbreviation is part of a list we compile. This will utilize a function and lookup table in the transform. 2024-09-18

II.H.2 Map all valid name subfields from a heading for an Agent entity access point, even if some of those subfields are not typically used 2024-06-12

II.H.3 We will not try to fix data when creating access points, and will just map the data as we find it 2024-06-12

II.I. Priorities

II.I.1. Milestones

II.I.1.a. Current milestone: BSR. MVP for Transform has been collapsed into BSR. Mapping Review has been abandoned. Publication has been collapsed into BSR or CSR as appropriate. Priority order for subsequent milestones: Post-Phase I Close-out, CSR [Phase II]. See discussion. 2024-10-23

II.I.1.b. Old milestone: MVP for Transform. Priority order for subsequent milestones: BSR, CSR, Mapping Review, Publication [milestone for transform will be created once we have MVP done]. 2022-07-27

II.I.2. Entity Types and Structures

II.I.2.a. We will focus initial mapping of MVP and BSR Milestones on singleton Work-Expression entities (non-aggregates), with aggregates and serials integrated in layers afterward. 2022-07-27

II.I.2.b. We will create a set of conditions to identify and exclude aggregates, serials, collections etc., adding them back and treating them appropriately in stages. 2022-07-27

II.J. $5

II.J.1. Preliminary processing for cultural heritage organizations and their collections 2022-08-24

II.J.1.a. Take information from id.loc's Code List for Cultural Heritage Organizations

II.J.1.b. Mint corporate body IRI for each nomen

II.J.1.c. Mint one collection work IRI for each organization using boilerplate for appellations based on institution label in code list and identifiers based on codes

II.J.1.d. Mint one collection manifestation for each collection work using similar boilerplate, including identifiers based on codes

II.J.1.e. Publish somewhere for re-use (Wikidata?)

II.J.2. When $5 indicates that a statement applies to an item entity

II.J.2.a. Mint one item entity/IRI for each occurrence of $5 2022-08-24

II.J.2.b. Relate the item to the published collection manifestation that corresponds to the code value in $5 2022-08-24

II.J.2.c. Illustration of model:

II.J.2.d. Example Mapping: MARC Record with Multiple $5's

II.K. $2 and 65X indicator 2

II.K.1. When there is no accompanying IRI, retain the source in $2 or 65X indicator 2

II.K.1.a. For a concept, use as skos:inScheme 2024-07-03

II.K.1.b. For a nomen, use as rdan:P80069 has scheme of nomen 2024-07-03

II.K.2. If we expect the source vocabulary to have an IRI somewhere (for example, a "Source Vocabulary" at id.loc.gov, or an RDA vocabulary at the RDA Registry), enter that information in the spreadsheet in the "Transformation Notes" column.

II.K.4.a. The transform will have to perform look-ups for the source IRIs. This should be easier than searching all the specific source vocabularies for specific string values, which will be done later in the transformation pipeline.

II.K.4.b. If the value of $2 cannot be associated with an IRI of a source vocabulary, then the transformation should output a message that a $2 value has been lost. Preferably, a report of all lost $2 values will be produced.

II.L. Reproductions and 533

II.L.1. 533 fields will not prompt the minting of two separate manifestations (one for the original and one for the reproduction)

Instead, this mapping and transform will mint a single manifestation. The project team realizes that in RDA, separate manifestations ought to be described in cases where one manifestation is reproduced as another. However, differentiating which MARC fields are "about" which of these manifestations is difficult due to inconsistent practices across cataloging communities over time. The group may revisit this at a later date, and welcomes contributions from the community in the form of transformation code that can reliably extract manifestation data for original and reproduction manifestations from a single MARC record. 2023-03-29

II.M. LRM/RDA/RDF Data Structure

II.M.1. Intermediate blank nodes and resources are never implied in this mapping

The assumption is that values are direct values for the RDA properties given. If otherwise, a transformation note is required.

II.M.2. When an IRI is given as a value, the mapping will not also include a corresponding label.

Labels should be retrieved via IRI by implementers, and unless an IRI is not present, are out of scope for this mapping. See discussion for more detail. 2022-04-20

II.M.3. Datatype/Object Properties

II.M.3.a. Where IRI values are expected, object properties should be used. In other cases, datatype properties should be used. 2022-06-22

II.M.3.b. Within spreadsheets, recording method column may be used to determine property type. 2022-06-22

II.M.4. Aggregates

II.M.4.a. We will model aggregates according to Official RDA structure, using aggregating works and aggregated expressions, where they can be detected. 2022-07-27

II.N. Identifiers

II.N.1. We will consistently mint Nomens for nomen strings for identifiers found in MARC data. See meeting notes. 2023-06-07

II.N.1.a Aligned with approach to minting Nomens, if a source is not present the identifier cannot be treated as a minted nomen. See discussion and II.C.1.a. 2025-01-04

II.N.2. We will not use outside IRIs to identify these Nomens (although these could be mapped later), or link to these from the Nomens that we create at this time. 2023-06-07

II.N.3. Provide a scheme for the Nomen ('in scheme' + LC vocab IRI) 2023-06-07

II.N.4. Add a status for invalid identifiers (use n/P80168 'status of identification'...) 2023-06-07

II.N.5. II.G.4.b will not apply for Nomens minted for identifiers. Paired 0XX fields are rarely used. 2024-06-25

II.N.6. The control number for a bibliographic description maintained by an agency is treated as an identifier for the manifestation described by the record.

I.e., the default entity for an identifier in a MARC21 record is Manifestation, in the absence of any fields indicating it is assigned to a different entity. See discussion and issue. 2025-01-02

II.N.7. Identifier subfields can be mapped to Nomen provenance properties, aligned with approach for 6xx. See discussion. 2025-01-02

II.O WEMI-to-Agent and WEMI-to-WEMI Relationships

II.O.1 WEMI-to-Agent: We will default to related agent of manifestation

When the relationship between an Agent and a WEMI Entity cannot be determined from the MARC field and relator subfields, the default will be a relationship with the manifestation. 2024-06-28

II.O.2 WEMI-to-WEMI: We will default to related work of manifestation

When the relationship between a described WEMI and an associated WEMI cannot be determined, the default will be a related work of manifestation. See 2024-7-17 meeting notes. 2024-7-17

II.O.3 We will map original RDA labels

MARC records are using Original RDA, so we will map Original RDA Labels that have changed or become deprecated alongside our mapping of Official RDA labels. 2024-06-28

II.P 245

II.P.1 Punctuation

For square brackets, decided to only strip surrounding brackets and [sic]. Strip ending punctuation for 245. See 2024-10-9 meeting notes. 2024-10-9

II.P.2 $n $p $s

$n, $p, and $s following $b other title information should be part of the title proper not other title information. See 2024-10-9 meeting notes. 2024-10-9

II.Q 264 $c Dates

Use date in 008 as publication date, if it has one. If we can’t get a date from a more reliable field, pick the 1st date in 264 $c. See 2024-8-7 meeting notes. 2024-8-7

II.R 3XX with $3 Present

The 3XX fields that map to a manifestation property (34Xs, 337, 338), $3 can be mapped to a note that states something like "[value] applies to: [$3]". See 2024-7-10 meeting notes. 2024-7-10

II.S 656, 657, 658

II.S.1 We will map to note on work.

See 2024-10-23 meeting notes for more notes on this decision. 2024-10-23

II.T 8XX

II.T.1 800 series added entry--personal name

Treat the same as 1xx and 7xx; they're like 7xx except with presence of numbering at the end. See 2024-10-30 meeting notes. See related Issue. 2024-10-30

II.T.2 841-88X

Everything after 83X we will not complete. Exceptions are: 843, 856, 857, 880, 881 (stay in Phase I) and 883, 886 (stay in Phase II). See 2024-12-4 meeting notes. 2024-12-4

III. Workflow

III.A GitHub

III.A.1. We will use semi-automated script to push changes directly to Master branch. We're not utilizing pull requests. 2022-7-27

III.A.2. When we close an issue, if it isn't self-explanatory, we will include a note and link to related decisions recorded in the decisions index at the time of issue-closing. 2022-06-08

III.A.3. Issue Phases

III.A.3.a. Project issues begin in the "to-do" category of the GitHub project, and are prioritized using Milestones.

III.A.3.b. Issues are self-assigned, and moved to "in progress" category at that time.

III.A.3.c. Once a first pass is complete, mappers move issue to "awaiting review".

III.A.3.d. If one or a few open questions are holding up the first pass, a mapper may move the issue to "almost done" column, adding a note in the issue explaining what needs to be done in order to complete a first pass. The self-assigned mapper will finish the mapping when the open questions are answered, or will find someone else to adopt the issue. Crystal will monitor "almost done" column to make sure nothing lingers unnecessarily. Once a first pass is complete, these issues move to "awaiting review". If a mapper believes the mapping is too complex for a single person to reasonably complete, and that the mapping would benefit from group review, the mapper will also label the issue "meeting discussion needed". 2022-09-21

III.A.3.e. Any project participant except for the person who performed the initial mapping may elect to take on the role of "reviewer" on a piece of the mapping. Reviewers self-assign issues from "awaiting review" to review mappings. Once review is complete, issues are moved to "ready for transform". 2022-09-21

III.A.3.f. Transformers select issues from "ready for transform" and write code for them. Once code is complete, issue is closed and automatically moved to "done".

III.A.3.g. If changes are needed after an issue has been moved to "done", the issue is re-opened and re-assigned, and moved to the appropriate column. Notes should be made in the issue to indicate to mappers that transformation code needs to be adjusted/checked against any changes.

III.A.3.h. If a reviewer makes changes to the mapping and the mapping has a tag indicating a transformer is writing code for that mapping, ("coding-ar", "coded-ar", "coding-rip", "coded-rip", "coding-rft", or "coded-rft"), the reviewer should add the "code re-check" label to the issue to indicate that transformers need to update the code. 2024-06-12

III.A.3.i. Once Transformers have re-checked issues with the "code re-check" label and made any needed updates to the code, remove the re-check label when done. 2024-10-29

III.B Google Sheets

Mapping contributors will edit the draft mappings in Google Sheets. 2022-05-18

III.C Transformation

III.C.1. Select fields to code, field by field

Select field using the main project board and assign yourself to the issue on GitHub. Do not code fields in "To Do" or "In Progress." It is OK to code fields in "Awaiting Review" or "Review in Progress" if the procedure below (III.C.3) is followed. It is best to select fields from "Ready for Transform"; follow the procedure below in (III.C.4). 2024-03-11

III.C.2. A field can be moved into "Done" on the main project board if two conditions are met:

(1) the coding is done; (2) mappers have moved the field into "Ready for Transform." 2022-07-28

III.C.3. When selecting a field to code in "Awaiting Review" or "Review in Progress":

III.C.3.a. Manually edit the issue by adding the appropriate label indicating the field's status on the main project board at the time of the coding. Either use "coding-ar" (for a field being coded while "Awaiting Review") or "coding-rip" (for a field being coded while "Review in Progress"). 2022-07-28

III.C.3.b. Add/Commit the code for the single field; include a commit message that includes the following: -m "Code for field XXX [awaitingReview OR reviewInProgress] #[issueNumber]." Example: "Code for field 100 awaitingReview #102." 2022-07-28

III.C.3.c. When coding is complete, manually edit the issue by removing the "coding-ar" or "coding-rip" label and replacing it with the "coded-ar" or "coded-rip" label as appropriate. 2024-03-11

III.C.4. When selecting a field to code in "Ready for Transform":

III.C.4.a. Manually edit the issue by adding the label "coding-rft" (i.e. "We are coding this field in the main project board's category 'Ready for Transform"). 2022-07-28

III.C.4.b. Add/Commit the code for the single field; include a commit message that includes the following: -m "Code for field XXX #[issueNumber]." Example: "Code for field 100 #102." 2024-03-11

III.C.4.c. When coding is complete, remove the "coding-rft" label and replace it with the "coded-rft" label. 2024-03-11

III.C.5. To complete a field:

III.C.5.a. Change the transformation-related tags from the appropriate "coding" tag to the matching "coded" tag. If the field was in "Ready for Transform", close the issue for the field. 2024-03-11

IV. Meeting Norms

IV.A.

We will talk and listen in turns, using hand-raising functionality in Zoom interface to order discussions. 2022-08-03

IV.B.

Agendas, set by Crystal and edited by anyone, will include time limits for items. Unused time can be rolled over to the next item. 2022-08-03

IV.C.

Timekeeper and note-taker will be assigned at the start of each meeting (as separate duties). Note-taking should rotate between UW members. Notes may be amended by anyone after each meeting. 2022-08-03

IV.D.

Off-topic but important items will be noted in a "Backburner" section of the notes/agenda in an effort to keep conversations focused. 2022-08-03