Hi Steve,
Indeed the NCBI PubChem team is really worried about having a resilient
service, at least that is what I recall of the conversation over sake.
But with the lower cost of hosting a sparql endpoint they may change
their minds.
Also of interest is.
https://jcheminf.biomedcentral.com/ar
Andy pointed at sequential OPTIONALs. One example I have seen had
nested OPTIONAL clauses to address a performance issue. Might that be
helpful here?
On 5/20/2021 5:43 AM, Andy Seaborne wrote:
On 20/05/2021 09:36, Martin Van Aken wrote:
Andy,
A big thanks for this - it gives me some paths
Ah - I read it as using SERVICE so you could send auth conveniently
which I have seen before.
The query execution context can have a HttpClient passed to it.
I thought this was in the documentation or an example somewhere but I
can't find it.
https://jena.apache.org/documentation/javadoc/arq
wouldn't you use a nested OPTIONAL here anyways?
If it is just one triple in the optional is less likely to be bad but
if the query uses the variable unbound later on, there will be a very
large number of results, many duplicates and not actually related to
the ?paper. I am guessing but I would
Thanks a lot, Andy.
And sorry, it seems I probably formulated my question the wrong way around:
How can I use your described approach for a federated sub-query, for
which (as it is embedded inside an outer query) one seemingly cannot
easily transmit separate/different credentials via
RDFConne
Please can we have a complete, minimal example.
On 19/05/2021 11:12, Mikael Pesonen wrote:
More info on this. When the causes of the two warnings are fixed, same
data is imported correctly and everything works.
So, when there are "too many" WARN level errors in importing data, the
graph becom
On 20/05/2021 09:36, Martin Van Aken wrote:
Andy,
A big thanks for this - it gives me some paths to explore. I think indeed
my biggest problems are in the optional parts - I'll run the test you
advised and also look in which case I may be able to get rid of the
optionals to avoid those situati
Hi Martynas,
Thanks a lot - that was exactly what I was wondering as indeed a lot of my
variables are just there to make sure I have them on the output but are
probably extending the search space a lot for no good reason. Did not know
I could wrap a query in a describe, this splitting the "what I w
I'm probably misunderstanding this graph pattern or the data
?paperiospress:publicationDate ?pubDate ;
iospress:publicationIncludesKeyword ?keyword;
iospress:publicationAuthorList [ ?idx ?author ] .
but just in case this author list is an RDF list, the
Martin,
Some of the OPTIONAL variables don't seem to be used anywhere else in the query.
Rather than using SELECT to pull the data fields, can't you use it to
only filter down the entities of interest, and wrap the whole thing
into a DESCRIBE to retrieve their full descriptions as graphs?
Somethi
Andy,
A big thanks for this - it gives me some paths to explore. I think indeed
my biggest problems are in the optional parts - I'll run the test you
advised and also look in which case I may be able to get rid of the
optionals to avoid those situations that could lead to a big amount of
results as
11 matches
Mail list logo
