-
Notifications
You must be signed in to change notification settings - Fork 10
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
Validation of examples for ELN-file format with RO-Crate validator fails #88
Comments
I actually noticed that validation might also fail because of some overly strict rules in the validator, e.g. the pattern for |
Hello, Have you seen #67 ? |
Hi @salexan2001, I wanted to clarify that, according to the RO-Crate Specification, the properties(shown in the above snippet) such as |
Thanks for clarifying! Apparently the validator I cited above has several issues. |
Hi again, This is indicated in the specification with the first sentence:
See also: crs4/rocrate-validator#14 |
Thanks for clarifying. Then we should definitely consider adding these properties, regardless of whether each system can put something useful in there or not. |
I think |
You're correct, removing this property doesn't impact ro-crate validity, but it was in the minimal ro-crate, so I added it. Now that it's there, it's there :p |
Hi ELN-FileFormat-Team,
I am currently working on implementing support for the eln file format into LinkAhead. I stumbled upon the following issue:
As the eln file format is supposed to be based on/compatible to the RO-Crate specification, I'd like to re-use an existing Python package (https://github.com/ResearchObject/ro-crate-py) to read its meta data. As loading eln-containers with this package did not work out of the box, I started checking the examples provided in this repository using an rocrate-validator. The result was that none of the examples is validated successfully by this validator, mostly because of missing meta data fields (actually belonging to schema.org) in the root data entity (see below).
For now, I can work around these missing fields and just ignore them during import, but I think it would be probably advantageous to fully comply to the RO-Crate-Specification.
Or did I maybe overlook something (e.g. using the wrong version of the specification)?
(Btw.: There seems to be another issue which prevents loading the example files with the
ro-crate-py
package which I will report in that repository directly. -> ResearchObject/ro-crate-py#202)Example output for the RSpace-example eln file:
The text was updated successfully, but these errors were encountered: