ONTOTEXT ANSWER:
For those of you who are just finding this for the first time, GraphDB operates a forward chaining algorithm, where statements are inferred and materialized at insertion time. This means some statements that are present in physical storage are explicit and some are implicit. All implicit statements are stored inside the default graph.
When sending any query towards GraphDB, you can use the `includeInferred` parameter to toggle if you want to include inferred statements or not. This parameter can also be configured on the UI via a button inside the SPARQL view. However, when you want to combine results, this isn’t viable – you rarely want to run the query twice and compare results!
This is why GraphDB comes with multiple special “named graphs”. In this case, we would want to use the implicit and explicit graphs. Those special “pseudo-graphs” aren’t materialized like all other graphs, so you can’t use them with all standard SPARQL constructs. Filtering and the GRAPH statement don’t always work as expected. Those statements are optimized for working with the FROM keyword.
Let us illustrate this, with the Graph Path Search algorithm. The algorithm allows you to look for all paths between two RDF nodes. So, let’s make a small data file about parts of the body and how they are connected.
You want to use this on a repository with some inference enabled. RDFS-plus is required at the least!
Then, you can query the data, using FROM NAMED twice.
And get as result:
So, both paths starting at the hand are of length 0, i.e., there are no intermediate steps. However, one of these is explicit and the other one – implicit.
You can use FROM NAMED in any SPARQL query to get reliable results about your explicit and implicit statements.




