Closed justgo129 closed 8 years ago
@justgo129 -- the file with the query should have a ".sparql" suffix in order to be run by the test suite.
@bduggan the tests fail because of: "ok 5 - 04-capitalization.sparql Encountered " "count" "count "" at line 4, column 26. Was expecting one of:
On Thursday, September 10, justgo129 wrote:
@bduggan the tests fail because of: "ok 5 - 04-capitalization.sparql Encountered " "count" "count "" at line 4, column 26. Was expecting one of:
... ... "from" ... "where" ... "(" ... "{" ... " I don't see the source of the error in any of the commits though. Is #154, which has been merged, a precondition to the tests passing for this change?
The SPARQL is not valid.
Also the csv file is not going to be what is in this pull request -- the output of the tests only reflects data that was ingested from t/data.
than as text (see the other files in t/results for examples)
I suggest pulling the code to a development environment, trying to get the tests to pass locally and then opening a new pull request once they pass.
Brian
Thanks, @bduggan. I had transformed the file into rapper and then output the file: rapper -o turtle http://eelst.cs.unibo.it/apps/LODE/source?url=http://purl.org/spar/biro -> biro.ttl
@zednis could you help with this? I'll then close the pull request.
OK, I've taken a look into this and based on http://stackoverflow.com/questions/10803657/sparql-count-query-using-jena-api I believe it is possible that the Jena SPARQL API does not support the following
(count(?variable) as ?binding)
This is supported by virtuoso which is why the query works against the production endpoint. (example -http://yasgui.org/short/VJIKng6yl)
To make this test pass I believe we will have to update the query to not use a bind on the count results.
ok, progress. I think the current failing is due to filenames.
t/results/06-tick132-datasetinstruments.txt should be renamed to t/results/05-tick132-datasetinstruments.txt
I now have the filename of the results correct and jena is able to run the query without throwing an error, however we have 2 issues at present
---------------------------------------------------
| dataset | instruments_on_platform_attributed_to |
===================================================
| | 0 |
---------------------------------------------------
@justgo129 after looking at the query and the expected results, are you sure you want this query in the gcis-ontology repo? These queries are run against the contents of t/data - not the production endpoint. They are not intended to be run against production content; as such, there are no instances of gcis:Dataset found by this query against the rdf in t/data.
Perhaps this query should be in the gcis-sparql tests?
alternatively, create a new rdf file with test instance data and put it in /t/data and update the expected results file to be based on the contents of that test instance data.
@justgo129 have you decided if you want to keep this test in gcis-ontology and add some input instance data for the test or drop this test from being in gcis-ontology?
Let's go with gcis-sparql for the time-being. @rewolfe do you see a reason for keeping this test in gcis-ontology?
@justgo129 Do we already have a test coverage for instrument/platforms? If not, I would go ahead and put some instance data in for the test like Stephan suggested. If you are not sure how to put instance data in, I can help.
On Fri, Oct 23, 2015 at 7:57 AM, justgo129 notifications@github.com wrote:
Let's go with gcis-sparql for the time-being. @rewolfe https://github.com/rewolfe do you see a reason for keeping this test in gcis-ontology?
— Reply to this email directly or view it on GitHub https://github.com/USGCRP/gcis-ontology/pull/151#issuecomment-150552856.
Robert Wolfe, NASA GSFC @ USGCRP, o: 202-419-3470, m: 301-257-6966
Sounds good, @rewolfe. Let's follow up.
Are we ready to re-engage with this ticket? I believe the next steps are to create some gcis-ontology test data with a handful of test instance data (does not need to reflect anything from the actual GCIS instance data) and update the expected results file to match the test instance data.
Sure. Let's keep this tabled until next week's code push because it will involve changes to the test suite.
Given the tests were failing and this branch is now completely out of date, I'm closing #151.
References #132.