Open cmungall opened 8 years ago
Why a new data type with a single document and field? Not much use for Solr with that... Why not just deliver it as a context package with the software? Versionable, re-usable, and reconstructable.
On 23 May 2016, at 23:55, kltm wrote:
Why a new data type with a single document and field? Not much use for Solr with that...
same could be said for the load metadata
Why not just deliver it as a context package with the software? Versionable, re-usable, and reconstructable.
how does the client currently introspect this?
The load metadata is not in the Solr index at this time. It is grabbed off of a log file on the server.
The client gets a lot of contextual information via NPM packages, which gets compiled into the runtime "environment". Or it's getting the information delivered via a global that server amigo provides in the browser.
When a client such as noctua acts as the intermediary between a non-URI/SemWeb stack component such as solr and a URI-based/SemWeb component such as Minerva, incorrect assumptions are made about how shortforms map to IRIs.
We should include a way to store the CURIE map that owltools used to load golr (currently this itself makes different assumptions, but this could be changed easily to use a CURIE map). For maximal flexibility this could be a jsonld context.
(This is all largely analogous to the SciGraph stack and behavior.)
Not sure the best way. It could be a config thing but I think it's better if it's included with the data. So a new document type, with only a single document, with a single field.
Alternatively, every document in golr could have its own CURIE map/context. This would provide maximum flexibility. But not clear if the bloat makes it worth it.