QuaRe is a tool for testing whether GitHub repositories of interest comply with certain quality criteria that they should fulfill according to the project type.
For the FAIR project type, often alternatives were modelled. For example, usage documentation is present if there is a section "Usage", "How to use", "Manual" or "User manual" in the README file.
The other project type definitions only have one possible value for each property. --> Extend them with reasonable values.
In this milestone 1 (Implement FAIR Project Type for Validation), the FAIR project type was added only to the SHACL part of QuaRe. Moreover, as discussed in the paper (cf. p. 5), SHACL is better suited for the overall use case than OWL. Therefore, the OWL part should be removed from QuaRe.
According to the specification, "shapes can specify one value for the property sh:severity in the shapes graph" (https://www.w3.org/TR/shacl/#severity).
Check if this is useful for QuaRe and how pySHACL handles this information.
The quality criteria on the specification page originate from Markdown content in the descriptions of node and property shapes. All descriptions contain tables that need to be formatted. For this, a CSS file is used because Svelte ignored selectors like table in <style> tags. This is because these tags are added at runtime.
Use re-rendering so that the style can be defined in the file SpecificationPage.svelte.
If a heading contains multiple relevant keywords, currently only one of those is recognized. After that, the next heading is checked. For example in "Installation and usage", only the installation part is recognized.
โ Remove "continue" from the for-loop in process_readme_sections.
At the moment, the repository representation is always constructed completely, independent of how many attributes are important for the project type. This increases the time until the validation result is presented to the user.
Therefore, the required methods / code words should be mentioned in the SHACL files. In the Python code, they should be mapped to functions via globals or dictionaries.
Use for example pytest to test the shacl_validator with the SHACL specifications (focus on FAIR project type). The main goal is to find possible errors in the specification.
Understanding and detailing the "Research Software Best Practices" presented in the poster by A. Iglesias-Molina and D. Garijo.
--> What exactly has to be present/absent in a GitHub repository so that it fulfills these criteria?
The validation of (public and private) repositories without a license file returns no results in the frontend. Instead, the spinner in the grey result button contiunes to spin.
At the same time, the terminal where Docker Compose is running, shows this error message (here shortened):
For example, a "Constraint Violation in OrConstraintComponent" does not contain a result path and therefore does not lead to an explanation. โ Investigate new possible violations and adapt shacl_verbalizer.py accordingly.
Hello, I came to test this software after reading your paper: "Specification and Validation of Quality Criteria for Git Repositories using RDF and SHACL"
The README states that we can launch the app via docker compose up after cloning the repository. In my experience (OS: Ubuntu 20.04), two additional steps are needed:
In the frontend directory, run npm install to install all the dependencies.
In the backend directory, run chmod +x backend_api.py to add execution permission.