ostrich-evaluate ingest misbehaves

[GreenfishK]

I tried to ingest the BEARB_day dataset using the following calls from a Docker container

/opt/ostrich/build/ostrich-evaluate ingest never 0 /ostrich_eval/datasets/bearb_day 1 88 # Creates only the first snapshot and then applies patches
/opt/ostrich/build/ostrich-evaluate ingest interval 1 /ostrich_eval/datasets/bearb_day 1 88 # Always creates a snapshot

I then tried to query two different versions using a simple query:

/opt/ostrich/build/ostrich-query-version-materialized 0 "http://dbpedia.org/resource/Kane_(wrestler)" "http://dbpedia.org/ontology/wikiPageOutDegree" "?"

/opt/ostrich/build/ostrich-query-version-materialized 1 "http://dbpedia.org/resource/Kane_(wrestler)" "http://dbpedia.org/ontology/wikiPageOutDegree" "?"

Either query yields the same result, no matter which versioning strategy:

Count: 2
http://dbpedia.org/resource/Kane_(wrestler) http://dbpedia.org/ontology/wikiPageOutDegree "600"^^<http://www.w3.org/2001/XMLSchema#nonNegativeInteger>.
http://dbpedia.org/resource/Kane_(wrestler) http://dbpedia.org/ontology/wikiPageOutDegree "601"^^<http://www.w3.org/2001/XMLSchema#nonNegativeInteger>.

My log file of the ingest also suggests that the added number of triples is incorrect, as it is always "2" for every version. Here is an excerpt:

0,33501,459,72,1398641
1,2,523,0,12707682
2,2,539,0,24016723
3,2,540,0,35325764
4,2,524,0,46634805
5,2,578,0,56731942
6,2,597,0,66829079
7,2,588,0,76926216
8,2,567,0,87023353
9,2,562,0,97120490
10,2,560,0,107217627
11,2,544,0,117314764
...

What am I doing wrong? This is the Dockerfile I used to build Ostrich: https://github.com/schreiner-peter/starvers_eval_ostrich/blob/master/Dockerfile.ostrich

[rubensworks]

It's been many years since I've worked with this code and benchmark, so I'm a bit rusty...

Are you sure you are ingesting using the change-based (CB) version of BEAR?

[GreenfishK]

I am ingesting using BEAR's initial IC and the computed change sets from the ICs because those provided by BEAR are not entirely correct in reflecting the changes. However, my files look the same as BEAR's change sets, it's just a matter of a few triples more or less within the change sets.

I then fit each positive and negative change set into the required directory structure

bearb_day/alldata.IC.nt/000001.nt
bearb_day/0/main.nt.deletions.txt
bearb_day/0/main.nt.additions.txt
bearb_day/1/main.nt.deletions.txt
bearb_day/1/main.nt.additions.txt
....
bearb_day/88/main.nt.additions.txt
bearb_day/88/main.nt.deletions.txt

[GreenfishK]

I think I have figured out the problem. There are two member functions populate_controller_with_version. One of them is attuned to BEAR's directory structure and the other one to the "{dataset}/{patch_id}/xxx.nt.additions.txt"-like structure. In my case, BearEvaluatorMS::populate_controller_with_version got called, although that's not what I wanted. From the documentation, I understood that the directory structure should be {dataset}/{patch_id}/xxx.nt.additions.txt. Maybe the documentation should simply be changed or the performance.cc should also be compiled because this is where I see that the other function gets called which is probably meant for arbitrary RDF triple sets.