Add "Required if applicable" as an option for a property in a resource template

[vitustang]

New feature proposed for Sinopia resource template: Currently one can designate a property as "required" in a Sinopia resource template. Conversely, the absence of this designation signifies that the property is "not required" and therefore "optional". This proposal suggests that Sinopia supports a third category: required if applicable?

Rationale: Some properties in a resource template are provided in case the resource being cataloged has such data. For example, an edition statement, a series statement, an ISBN. Not all resources have such data. Therefore, one cannot designate such properties as "required". Having a "required if applicable"option would allow the template creator to convey to the user of the template that a property is not required in every description created using that template, but when the resource being cataloged has such data, then the use of the property is required. Having this property attribute will cover the gap that currently exists between what is required in every description and what is truly optional and up to the cataloger's judgment.

The concept of "required if applicable" can be found in the National Level Full and Minimal Requirements in MARC 21 documentation, in OCLC's Bibliographic Formats and Standards, and in the PCC BIBCO and CONSER standard record specifications.

Example: Edition Statement in the PCC BF2 Instance (Monograph) template

Describe alternatives you've considered:

1. Use the "Remark" feature to add such instruction for catalogers. The drawback of this alternative is that the cataloger would have to open the remark in order to see the instruction.

2. Put "required if applicable" in the label of the property. The drawback of this alternative is that it uses the label to serve instruction purposes. And in order to be consistent, we will have to do it for every property, i.e. indicating in the label whether it is required, required if applicable, or optional. Another argument against this alternative is that if we have a property attribute for "required" "not required", then this "required if applicable" category should naturally be part of that attribute, so choosing an alternative way to do it does not make logical sense.

[justinlittman]

To be clear: Sinopia would not validate the presence of a field that is "required if applicable", right?

What sort of an icon or visual indicator might suggest "required if applicable"?

[NancyL]

I am a little worried about templates getting cluttered through too many individual icons meaning different things. And where do we stop? We also have "PCC core" and "PCC recommended" (and recommended if applicable) and additional guidelines beyond that from RDA and forthcoming application profiles. We have decided to put PCC BSR guidelines in remarks in the PCC templates from RDA and forthcoming application profiles. Catalogers will need to look at the remarks whatever. I admit I would like the remarks field to be more flexible--the ability to have more than one remark but to see them in a list--but that is a bigger project.

I am strong against option 2 as given above. The PCC MAPs group will be using labels to overlay the BF structure with RDA terminology and they should not include instructions. Instructions that are there currently (only Primary Contribution I think) will be removed.

[justinlittman]

Display remarks on the editor form instead of popover?

[vitustang]

It is understood that Sinopia will not be able to validate "required if applicable" triples as it has no way to know whether the property is applicable for a particular description or not. The proposed feature has two values outside of validation:

• as an aid to catalogers to make clear which fields in the form they have to fill out
• allow identification of properties in a resource template, which is the embodiment of an application profile, that are considered required/essential. This could be useful in analyzing/understanding an application profile

I personally prefer explicit textual indicators over icons. People have a tendency to not see icons, or not remember what they stand for and just ignore them. In terms of the design, I would defer to Astrid.

To me, things like "required", "required if applicable", "optional", "repeatable", "not repeatable" are basic information about a field. They are different from "instructions", "interpretations", "remarks", "notes", which tend to be longer and require sentences. It would be unwieldy to include such things in the form itself. Some sort of on-demand display mechanism would make more sense.

[jcoyne]

To me, things like "required", "required if applicable", "optional", "repeatable", "not repeatable" are basic information about a field.

To a computer program, the terms "required", "optional", "repeatable" and "not repeatable" describe syntactic validations. "required if applicable" is a semantic validation. Currently the editor understands the syntactic descriptions, and it is important to us to keep them separate from the description of the semantics, which our editor has little knowledge about. It's impossible to comprehend the semantics of data without first having valid syntax, so it's helpful to keep these at different layers apart.