Open kerstarno opened 1 year ago
I agree the BPG is an appropriate place to provide a list of values for the relevant eas elements. Is there one I can put together to try some layout configurations?
If you wanted to, you could maybe use @maintenanceEventType
. The current values are pretty straight-forward, I'd say, and we have a short description in the EAC-CPF 2.0 TL (https://eac.staatsbibliothek-berlin.de/schema/v2/eac.html#attr-maintenanceEventType) for each of them.
Here are some initial thoughts re the aspects that we should/could include when presenting the EAS values:
Also agree that the BPG is the most appropriate and useful. Thanks for testing out how this would look, Iris.
After almost a year, I have an example of a value list on the BPG: https://saa-sdt.github.io/EAS-Best-Practices/docs/value-lists. I've set up a couple more attributes in a separate branch called "additions-to-content": audience and contactLineType. Please review and leave comments and suggestions :)
Hi Iris,
thanks very much for this update. I've made some changes to audience and contactLineType with regard to the information about their expected use in EAD 4.0.
As for the example in the BPG:
<control>
as to whether the EAS lists are used or whether the values are taken from another list. When elements or attributes have constrained data values, i.e. in EAC-CPF 2.0 or when EAD 4.0 is used with "EASList" as the encoding source, choose the appropriate term as defined in the EAS tag libraries. Some examples can be found below. @addressLineType
, the information should be presented in the same way as the examples for @audience
and @contactLineType
, i.e. with a distinction between the uses in EAC-CPF 2.0 and EAD 4.0, I'd think.
Creator of issue
The issue relates to
Wanted change/feature
@...Encoding
attributes within<control>
, there was the decision to make sure the EAS value lists are defined somewhere outside of the schema, maybe also including some more descriptive information about what each value means and when it would be recommended to be used. There also should be a possibility for the community to suggest changes or additions, e.g. in the context of the annual minor revision cycles. While the conversation involved the option of exploring to use SKOS for this, it might also be worth considering whether this could become part of the Best Practices Guide.