Open mielvds opened 10 months ago
Thank you for you comment!
The list was created in around 2017 and the type of dash followed the LoC page at that time as did the values.
Changes of type of dash might cause other problems but we will look into that!
Addition of missing LoC values will be suggested.
A plan for an update will be setup by the DILCIS Board.
Hi,
Here's the char codes of the m-dash, space, and the common dash found on a regular keyboard:
Because this may break compatibility in some implementations, maybe we should wait for a major version of the specification. I'm not sure. We should ask developers to see if they have any issues on updating the vocabulary on a minor version of the specification (any thoughts on this @carlwilson, @luis100, @shsdev).
The suggestion is:
Board members acknowledgment of the issue: Tick the box in front of you name to indicate that you have looked at the suggestion.
Voting (Decision making will be carried out on the basis of majority voting by all eligible members of the Board. In the case of a tied vote, decisions will be made at the discretion of the Chair)
Tick the box in front of you name to say yes to the suggestion.
7 DILCIS Board members have acknowledge the issue 7 DILCIS Board members agree with the solution
The suggestion of updated list will be part of the next release of the specifications.
A new issue will be created for the hyphen which will need to be part of the next major revision.
Hi @karinbredenberg , has the issue for the hyphen been created yet, or should I go ahead? There is also no milestone for next major version 3.0 yet
Hello!
The values in https://earkcsip.dilcis.eu/schema/CSIPVocabularyContentCategory.xml are derived from https://www.loc.gov/preservation/resources/rfs/TOC.html.
I had two questions about these:
We noticed that the hypen character from https://www.loc.gov/preservation/resources/rfs/TOC.html got turned into a m-dash character in https://earkcsip.dilcis.eu/schema/CSIPVocabularyContentCategory.xml. Was this intentional? Although not ideal, we do some string matching on the value of
@TYPE
and it can cause problems along the way.Some values from https://www.loc.gov/preservation/resources/rfs/TOC.html are missing. Are there plans to eventually add those as well or are they left out on purpose? We have some use cases that would require for instance "Scanned 3D Objects (output from photogrammetry scanning)"
Cheers!