Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Create python module to validate processed data #18
Create python module to validate processed data #18
Changes from 15 commits
8c1dd85
d181201
fc37a5e
68aed79
f49e040
644a4c9
f752d17
c4dd67b
230ac90
458da5e
1e3697e
f35255b
379c107
2a3e61c
b9b3175
c150d15
8b25331
da2cebf
de56554
1a49eab
26e0925
9e92d70
3133735
f0d889a
0d501bc
3cd8a72
a3917f9
2678023
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
not sure that that file does, but all files should eiter be in lebedigital (the actual functions), in tests (the tests for these functions) or in minimumWorkingExample (the pydoit workflow that processes the data for the minimum working example). The folder usecases/Concrete is deprecated.
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.
That file is not used anymore, I think that was an accidental commit
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 file is still in Concrete, please remove it?
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 file is also outdated, the conda environment at the top level is the one and only to be used.
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.
We can ignore these commits then, all the libraries I need are already part of the environment file.
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've also deleted the validation.py from Concrete
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.
@joergfunger For the tests, is there a graph that I can use to test my code? The usecases/MinimumWorkingExample/emodul/processed_data folder is empty but I would need an EM_Graph.ttl file or so to test the validation. I can also just create my own otherwise from the data.
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.
Could you talk to @PoNeYvIf on that? For the tests, it would also be possible (and maybe even better) to create your own very simple test cases (it does not have to be related to a very specific ontology, but rather a very general one such as foaf or prov). In particular make sure that there are errors existing such that those can be returned and processed. We could also have a short phone call on that.
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.
E.g. if we know that we test for machine ids via shacl, we could get the machine IDs from the global KG that are referred to in the local KG. This would of course mean that every time we add a rule we have to think about the SPARQL query and the information that could be contained globally and not locally, i don't know if this is feasible.
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.
Yes, let's try to create the queries, let me know when it's okay for you.
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.
Not sure if I would always download the complete global graph. It would rather be necessary if particular instances that are referred to in the local graph (e.g. the testing machine that has already be created, or the mix_design we are referring to when adding a new Youngs modulus test) is existing. So for the specific tests, we would first generate the mix design, and upload it to the global KG. Then we would create a Youngs modulus test that references an instance of the mix design (without creating the same instance again). By uploading that then to the KG, these two data sets (mix design and Youngs modulus test) are automatically connected. And before uploading the Youngs modulus KG, we would have to check, if this instance of the mix design is already existing in the global KG (and potentially further properties apart from the id, but that is not necessary right now).
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.
As for the sparql query, we somehow know in the local KG generation what classes we expect. So the sparql query should return the ids of all instances of a given class - that should be quite general and would not require rewriting the sparql query each time we have a new test.
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.
Maybe we should have a talk together with @firmao to discuss the specifics?