Versa: Path-Based RDF Query Language
by Chimezie Ogbuji | Pages: 1, 2, 3, 4

Variables

Like their XPath counterparts, Versa contexts are associated with a set of variable bindings. These variables can be referred to by variable references that evaluate to the associated data type value.
These are quite different from SPARQL variables. The latter are Skolem variables which are bound to solutions by the query processor. The most common way Versa variables are bound is by an outside process or host language (XSLT, perhaps) before an expression is evaluated by the query processor. However, it is not inconceivable to think of such bindings to be created as the result of another query. Consider the following sequence:

I.

SELECT ?person
WHERE
  { ?x foaf:name "Chimezie Ogbuji";
       rdf:type foaf:Person }

II.

distribute(
  $person <- foaf:knows - *,
  '(. - foaf:made -> *) - list(rdfs:label,dc:title) -> *',
  '. - foaf:name -> *',
)

Here we wish to get the label or title of everything made by anyone who knows me as well as the names of these people. We do this with the distribute function (discussed later) and by an interpretation of the way both query languages use variables independently.

Versa Functions

The standard Versa functions include those listed in section [7] of the Versa specification (as well as the functions for converting between data types, listed in section [3.3]). However, we shall focus on four of the more fundamental of these.

Distribute (Data Aggregation)

The distribute function is the most common way data is extracted from targeted resources in the underlying graph. It is also the most difficult to use the first time around because of the format of its result. Below is a diagram of how the distribute function works:

Figure 2. Distribute Execution Diagram

Mathematically, the distribute function is best thought of as the cartesian product (where each pair is the result of applying the expression with the item as the context node) of the list of items in the source list and the list of expressions that follows, grouped in the order of items in the original set.

Type (Class Membership)

The type function returns all members of the given class (or list of classes). At a minimum, it is a short hand for

However, the underlying query processor can refer to class membership rules (from a defining OWL/RDFS ontology or schema) in determining its result. 4Suite's implementation follows the rdfs:subClassOf relationships (starting from the given classes) transitively to include members of derived classes (as given by RDFS9).

Properties

The property function returns the names of all relationships going out from (default) or coming in (with vtrav:inverse as the second argument) to the given resource. This is another situation where the query processor could take advantage of other standard RDFS rules.

Imagine you wanted to determine all the possible predicates (properties)—besides rdf:type—that can be expressed on instances of any class. The following are queries written in both SPARQL and Versa for this purpose:

SPARQL

SELECT DISTINCT ?Property
  WHERE { ?R rdf:type ?Class .
        OPTIONAL { ?R ?Property ?Object .
                   FILTER ?Property != rdf:type } }

Versa

difference(
  properties(set(all() |- rdf:type -> *)),
  set(rdf:type)
)

The underlying query processors in both cases can take advantage of RDFS Extensional Entailment Rules or OWL property restrictions (owl:onProperty) to process the request more efficiently and completely.

Filter

The Versa filter function has the same form as distribute, but returns a list comprised of the original items where the result of evaluating every expression as a boolean filter is "true." This kind of filtering is also discussed in [3.2] and [11] of the SPARQL Specification:

Value constraints take the form of boolean-valued expressions; the language also allows application-specific constraints on the values in a query solution.

Pages: 1, 2, 3, 4

Next Page