Need views of RDF data about sparql-dev HOT 12 OPEN

So the proposal would be to have some way of creating a persistent “named CONSTRUCT query” that can then be used in future queries like a named graph.

from sparql-dev.

I don't recall writing it in a paper anywhere so I'll briefly describe it here as best I recall it:

Each CONSTRUCT rule R in a .map is indexed by predicate into ByP. At query-time, a query Q is parsed and each triple constraint is mapped to the list of Rs that could satisfy it. The triple pattern T in Q is substituted with a disjunction of each the rule body B corresponding to each R in Rs. The variables in B are substituted with the terms in T which correspond to those variables in R. Duplicated invocations of an B (those with compatible variable assignments) are eliminated. The final query should give you the same answers as if you had merged the results of running each R separately on the data. This means the rules are treated as orthogonal i.e. no rule head gets to match the body of another rule.

from sparql-dev.

An approach to named "profiles" has been introduced as an ietf internet draft.
It is relevant to this discussion at least with respect to issues of naming and discovery.

from sparql-dev.

Dynamic views, might also be a corollary to named subqueries which is a function I miss.

from sparql-dev.

there are two aspects to this:

• where the reference may appear : in an http request, in a DatasetClause, or in something analogous to a ServiceGraphPattern
• what result it produces : a graph or solution sequence

in a dataset clause, permit a graph only.
in a service analog, permit a solution sequence only.
the the protocol level, permit both.

where the reference in a service analog is not a constant, this relates to #19.
there are also issues related to argument passing.

from sparql-dev.

Removing "SPARQL: " on transferred issue.

from sparql-dev.

Using SPARQL construct like semantics to define RDF views could be computationally expensive. If views are allowed to be recursive, then this is equivalent to backwards chaining (query time) inference.

from sparql-dev.

@jpcs Yes, I think it could be expensive. Question here is for the system owner to decide on materialized or non materialized views. Implementing e.g. OWL-RL as a view should be possible, turning it on should be a owner decision.

Can views be efficiently implemented by query rewriting in the common cases?

from sparql-dev.

Can views be efficiently implemented by query rewriting in the common cases?

if there has been work which demonstrates that static query rewriting would necessarily reduce the complexity below that of equivalent dynamic recursion, please provide a pointer.

from sparql-dev.

If nothing else turns up, SWObjects used .map files which were basically a bunch of CONSTRUCTS. It executed queries over the virtual product of the CONSTRUCTS by doing a query rewrite to the appropriate parts of the rule bodies. example: https://github.com/ericprud/SWObjects/blob/sparql11/tests/bsbm/db2bsbm.map

from sparql-dev.

is there somewhere a description of the mechanism?
one which discusses the complexity?

from sparql-dev.

to return to the question raised by bolleman's

Can views be efficiently implemented by query rewriting in the common cases?

by this description, the only difference between static rewriting and entirely dynamic sub-queries would be that, in the static case, one could cache the effective query so that it need not be recomputed.

from sparql-dev.