Jimmy Lin

@rodrigonogueira4 that's faceting ;) ... which brings us back to #46

Bumping this - @x389liu you should work on this. The Core18 instructions in the README can now just be replaced by the Solrini docs in Anserini.

I'm leaning to `P159`. This leaves open the possibility that a relation might not align perfectly with a fact property, so we can't do this mapping up front. So, just...

And furthermore, I would change to `has-subject` and `has-object` to make sure that it is obvious that the FACT or RELATION should be in the first place in the triple.

I don't think name is accurate: `mrtydi-v1.1-miracl-ar`; should probably be something like `miracl-v1.0-ar`?

hi @AileenLin - if you merge in main trunk, the scores should be updated and match? Also, can you compare speed with `-storeDocVectors` and using your new implementation?

This is ready for review. Interestingly, this PR also fixes a bug in bglinking regressions; i.e., the implementation before was actually not correct.

Here's my revised thinking on this: we should probably just store the link structure into an HBase table: row key = reversed URL (e.g., house.gov.www) column family = "link" column...

Here's what I'm thinking the REST API will look like, modeled after the Wayback REST schema: `http://host/table/URL`, where the `URL` would be something like `http://foo.bar.com/`. The output would be JSON,...

The id -> URL mapping is encoded in a Lucene FST, which is relatively compact. The client can load this in memory and perform the mapping. The idea (mostly in...