-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Principle 4.1 in its current wording conflicts with principle 1.1 #706
Comments
When it was written principle 4.1 was for the crucial metadata but of course there can be other metadata. This will be put on the agenda for the DILCIS Board. |
Hej Karin
I have been analysing the existing CITS and I do see consistency in the placement of standardised vs non-standardised metadata, so will make appropriate changes in eHealth1 and note for 3D. One question; if there is non-standardised metadata, say techmd placed in a sub-folder in rep/data, should we refer to it in the dmdSec of the mets file?
Other than this I would also like to discuss Archival collections, this is likely a requirement for 3D Product Models (i.e. product assembly structures) and I am envisaging a master metadata only AIP which holds a product structure.
Also, my analysis of the current CITS has given me a good checklist of possible extension points and constraints for a new CITS. Is this useful for the Guideline?
Again also, I have identified anomalies and improvement points for CITS as well as for eHealth1, e,g, folder naming in eHealth2. Should I just raise these as issues in GitHub?
Thanks
Stephen
Stephen Mackey
Senior Consultant
Penwern Limited
+33 668 397 453
***@***.***
From: Karin Bredenberg ***@***.***>
Sent: Wednesday, July 19, 2023 1:29 PM
To: DILCISBoard/E-ARK-CSIP ***@***.***>
Cc: Stephen Mackey ***@***.***>; Author ***@***.***>
Subject: Re: [DILCISBoard/E-ARK-CSIP] Principle 4.1 in its current wording conflicts with principle 1.1 (Issue #706)
When it was written principle 4.1 was for the crucial metadata but of course there can be other metadata.
This will be put on the agenda for the DILCIS Board.
—
Reply to this email directly, view it on GitHub<#706 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIKSFYLAA3C63MR7Z52VGR3XQ7AIXANCNFSM6AAAAAA2OKVVU4>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
The issue have been discussed on todays DILCIS Board meeting and we agreed upon editing the wording so its a well-formed format instead. An update of the wording will be made and a PR will be made for the DILCIS Board to review later on. |
The suggestion is:
Board members acknowledgment of the issue:
Voting Tick the box in front of you name to say yes to the suggestion.
|
7 DILCIS Board members have acknowledge the issue The PR will be part of the next release of the specifications |
Principle 1.1 states that "it must be possible to include any data or metadata in an information package regardless of its type or format" but principle 4.1 states that "metadata in the information package must conform to a standard". The text for principle 4.1 introduces the concept of "crucial metadata". Does 4.1 only apply to "crucial metadata"? In which case the principle needs to be more specific and in order for validation not to be problematic, acceptable "crucial metadata" standards need to be defined. Is "crucial metadata" the only metadata allowed in the /metadata folder?
The text was updated successfully, but these errors were encountered: