-
Notifications
You must be signed in to change notification settings - Fork 0
Implement Metadata File expectations #49
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
Conversation
|
Will update to deactivate the troublesome shapes with |
|
Done, ready for review |
| except Exception as e: | ||
| if logger.isEnabledFor(logging.DEBUG): | ||
| logger.exception(e) | ||
| return True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to pass the validation if there is an issue with the metadata. What I mean is that we can't tell if the exception is:
- from an issue with the libraries / code,
- or the metadata file,
e.g. if the validated file has an issue such that as_dict fails, the validation might still pass
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The base profile has a few checks for this sort of thing - valid JSON-LD, flattened & compacted, has a @graph, etc. If as_dict fails, it'll trigger one of those. See https://github.com/crs4/rocrate-validator/blob/dfe0136517196802b0a976e54da3f84a572780b6/rocrate_validator/profiles/ro-crate/must/0_file_descriptor_format.py#L64
|
|
||
|
|
||
| @requirement(name="RO-Crate context version") | ||
| class FileDescriptorExistence(PyFunctionCheck): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super minor issue but this isn't really the purpose of the class / method below - could be renamed more appropriately :-) e..g. ROCrateContextVersion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah my lazy copy-pasting has caught me out :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
| """ | ||
| try: | ||
| json_dict = context.ro_crate.metadata.as_dict() | ||
| context_value = json_dict["@context"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd maybe add a if not context_value check for safety here if context is missing, None or empty :-) and add an issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one's caught in the base profile too - https://github.com/crs4/rocrate-validator/blob/dfe0136517196802b0a976e54da3f84a572780b6/rocrate_validator/profiles/ro-crate/must/0_file_descriptor_format.py#L128
@contextMUST be "https://w3id.org/ro/crate/1.2-DRAFT/context" (i)(i) expanded to support 1.2-DRAFT, 1.2, or later minor version, to align with the other rule.
Adds a few example crates with variations on the
@context, because this can't be modified with SPARQL.Includes a workaround for crs4#126 (which means theno longer applicableconformsTocheck in the 1.1 profile is unskippable) - by disabling reporting of inherited profile checks when checking the valid 5s crates. I think this is ok as we really only need to test that the five-safes-crates profile is working, not the inherited ones.Also deactivates the
conformsTocheck in the 1.1 profile so it doesn't interfere.