Package org.aksw.jena_sparql_api.algebra.utils

Class VirtualPartitionedQuery

java.lang.Object
org.aksw.jena_sparql_api.algebra.utils.VirtualPartitionedQuery
public class VirtualPartitionedQuery extends Object
Notes on path resolutions: - Aliased paths do not appear to make sense here: - One might think that aliases could be used to resolve properties in templates of partitioned queries such as ?s rdfs:label ?v1, ?v2. (E.g. consider a base table with multiple columns of alternative labels). If this is the way it is mapped, then we simply accept it here. There is no need to resolve rdfs:label to e.g. only ?v1 here - if this is desired, the place to where to "fix" this is in the partitioned query. - There is also does not appear to be a good reason / user case for aliases to affect the naming of variables: The output of the resolution in a virtual RDF graph according to the partitioned queries. In a virtual RDF graph, the naming of the variables are meaningless anyway, as the rewriting system on top just cares about subject, predicate and object positions but not how they are named.
Author:
raven

  • Constructor Details

    • VirtualPartitionedQuery

      public VirtualPartitionedQuery()

  • Method Details

    • unionTernary

      public static Fragment3 unionTernary(Collection<? extends Fragment3> items)

    • unionUnary

      public static Fragment1 unionUnary(Collection<? extends Fragment1> relations)
      Create a union from a given collection of unary relations If the collection is empty, return a relation with an empty (unit) table. TODO Move to ConceptUtils
      Parameters:
      relations -
      Returns:

    • union

      public static Fragment union(Collection<? extends Fragment> items, List<org.apache.jena.sparql.core.Var> proj)

    • rewrite

      public static org.apache.jena.query.Query rewrite(Collection<Fragment3> views, org.apache.jena.query.Query query)

    • toViews

      public static Collection<Fragment3> toViews(org.apache.jena.query.Query query)
      Convert each triple pattern occuring in the template of a SPARQL construct query into a ternary relation. This is a somewhat poor-man's approach to creating views over rdf data: An improved rewriter would not treat the triple patterns in isolation, but rather take care of doing self-join elimination if multiple triple patterns of a view match that of a query.