Label service

Stardog 10.0 offers a new SPARQL service to retrieve human-readable labels for resources in your data. This facilitates writing SPARQL queries that no longer need to know how labels are modeled in the data, for example, using rdfs:label, skos:prefLabel, or any combination of other properties. Stardog will handle that behind the scenes based on your database configuration.

Page Contents

Introduction
Examples
Interaction with other features
Limitations

Introduction

Querying labels in the data is, somewhat surprisingly, not all that easy. It’s supposed to be a trivial matter of adding rdfs:label triple patterns to your query but there are complications. What happens if the data uses a different predicate for labels? What if you integrate multiple datasets that use different predicates? Some of them can be Virtual Graphs (VGs). The data can use labels in different languages. The list goes on.

Stardog 10.0 introduces a new SPARQL service that aims at isolating queries from these (and other) complications. The idea is to let query authors write simple ?s stardog:label ?label triple patterns (where the built-in stardog: prefix resolves to tag:stardog:api) and have the query engine evaluate it based on the new database option label.properties. That option lists all predicates that specify labels in your data (which by default is just rdfs:label). Finally, the new service can take advantage of Full-Text Search (if enabled) to look up entities by keywords in the label.

Examples

stardog:label is a short syntactic form:

prefix stardog: <tag:stardog:api:>

SELECT ?person ?label {
    ?person a :Person ;
            stardog:label ?label
}

In place of ?person, one can use a concrete IRI to look up label(s) of a specific node in the graph. Behind-the-scene stardog:label is rewritten into a union over all properties configured via label.properties.

The longer SERVICE form allows one to specify language tags to retrieve only labels in a particular language. This assumes that labels are stored using language-tagged RDF literals, such as "Mueller"@en or "Müller"@de.

prefix stardog: <tag:stardog:api:>

SELECT ?person ?label {
    ?person a :Person .
    SERVICE stardog:labels {
       [] stardog:entity ?person ;
          stardog:label ?label ;
          stardog:lang "en" 
    }
}

(note that the service IRI is stardog:labels while the short syntax predicate is stardog:label).

Regardless of the syntax, the service can be used to look up entities by labels:

prefix stardog: <tag:stardog:api:>

SELECT ?person {
    ?person a :Person ;
            stardog:label "Smith"
}

See below for how the execution of this query changes depending on whether the database has full-text search enabled or not.

Interaction with other features

The query engine can evaluate the label service differently depending on what other features are enabled for the database.

Full-text search

The label service can take advantage of our Lucene-based keyword search when looking up entities by their labels. If full-text search is enabled, the query engine transforms stardog:label predicates with bound labels

prefix stardog: <tag:stardog:api:>

SELECT ?person {
    ?person a :Person ;
            stardog:label "Smith"
}

into FTS patterns:

prefix stardog: <tag:stardog:api:>
prefix search: <tag:stardog:api:search:>

SELECT ?person {
    ?person a :Person ;
            rdfs:label ?label 
    SERVICE search:textMatch {
      [] search:result ?label ;
         search:query "Smith"
    }
}

This means, the query can find not only people whose label is precisely "Smith" but also those where it’s a part of the name, like "John Smith".

Named graphs

Normally SPARQL services do not interact with the GRAPH or FROM keywords. This is also true for our full-text search service. The label service is, however, different: it allows matching labels in specific named graphs:

prefix stardog: <tag:stardog:api:>

SELECT ?person FROM :human_resources {
    ?person a :Person ;
            stardog:label ?label
}

When looking up entities by a specific keyword, full-text search (if enabled) will be conducted over the entire full-text index but the joined rdfs:label pattern will restrict the results to the right graph(s).

Virtual graphs

If the query dataset includes Virtual Graphs, the label service will be evaluated over them. The exact behavior depends on whether the label query term is a constant. If it is a variable, the label service will first be translated to the union of triple patterns based on the label.properties option (for example, rdfs:label). The resulting pattern will then be translated to the VG’s target language, e.g., SQL, and executed in the usual way.

If the label query term is a constant, however, the query engine will add an equality filter before sending the query to the VG. That should have the same effect as querying for labels locally without full-text search (at some performance cost depending on the VG backend and its available indexes).

The label service supports VG caches. If the query accesses a cached VG, the label service pattern will be sent to the cache node as-is. Thus, it can benefit from the full-text search index if it is enabled on the cache node.

Reasoning

The label service does not interfere with reasoning. The query patterns other than stardog:label are evaluated with or without reasoning based on query configuration.

However, there is one particular limitation: the service currently ignores schema axioms and rules which may derive new rdfs:label facts. Note that rdfs:label (as well as other common label properties such as skos:prefLabel) are annotation properties in OWL and their use in axioms and rule heads is not recommended. Instead, one may add extra properties to the label.propeties database option.

Limitations

Currently known limitations of the label service are the following.

Limitation with unbound label: When full-text search is enabled for the database and the object is not bound for patterns with stardog:label, only entities with exact matches for the label.properties are returned. For example, for the following queries only entities with exact matches for the labels "john" or "smith" will be retrieved:
```
?entity stardog:label ?label .
VALUES ?label { "john" "smith" }
```
or
```
?entity stardog:label ?label .
FILTER (?label IN ("john" "smith" ))
```

Introduction
Examples
Interaction with other features
Limitations