Preference patterns for SPARQL (1.1)

Question

Inspired by a few related questions (in particular this one), I wanted to ask a more general form of the question: how can I specify preferences for basic graph pattern matching in SPARQL (1.1) such that potentially many lower preferences are only matched if a higher preference cannot be found?

It seems there are a few potential solutions and I hope to gather some alternative patterns, some of which may work best in different concrete scenarios.

To make the general question concrete, but in a way that can easily be generalised, say I want to get the labels of each resource of type foaf:Person where, in order, I prefer the values from the following predicates:

foaf:name
skos:prefLabel
skos:altLabel
rdfs:label
(potentially more)

The basic query in SPARQL would be:

PREFIX ...
SELECT ?person ?name
WHERE {
  ?person a foaf:Person ; foaf:name ?name .
}

How can this query be adapted to return names from predicates in the above preference order such that values for a given predicate are only returned if no value is returned for a higher-preference predicate? (I.e., if we find a foaf:name that suffices, else if we find a skos:prefLabel that suffices, else ...).

Answer 1

4

A sequence of OPTIONALs gets a sort of conditional testing but it does not allow the input from VALUES or the rest of the query.

SELECT *
{
  ?person a foaf:Person .
  OPTIONAL { ?person foaf:name      ?X  }
  OPTIONAL { ?person skos:prefLabel ?X  }
  OPTIONAL { ?person skos:altLabel  ?X  }
  OPTIONAL { ?person rdfs:label     ?X  }
}

To allow the input to be defined not by the syntax order (returns one value at the top pref level):

SELECT *
{
  VALUES (?p ?pref) { 
       (foaf:name 1) (skos:prefLabel 2) 
       (skos:altLabel 3) (rdfs:label 4) 
   }

  ?person a foaf:Person .
  ?person ?p ?o 
} ORDER BY ?pref LIMIT 1

Given that used as a subquery, you can use it to get the ?p and all all ?person ?p is you want all values.

link

answered 31 Jan, 05:05

AndyS ♦
9.6k●2●7
accept rate: 33%

+1 That second solution is really rather neat

(31 Jan, 08:02) Rob Vesse ♦

+1 for the first solution.

Regarding the second solution, I was thinking along similar lines, but even as a sub-query, doesn't it mean that you only get one name for one person and not one name for each person?

For testing:

PREFIX dc:      <http://purl.org/dc/elements/1.1/>
SELECT *
WHERE
{    SELECT *
     {
       VALUES (?p ?pref) { 
          (dc:title 1) (dc:creator 2) 
       }
       ?book ?p ?label .
     } ORDER BY ?pref LIMIT 1 
}

Against: http://sparql.org/query.html

Returns one result for one book.

(31 Jan, 12:34) Signified ♦

Ok, you want more than a single item -- the data in /books isn't rich enough for testing. We need the old maximum trick ... updated to SPARQL 1.1. And a new answer.

(31 Jan, 13:19) AndyS ♦

Answer 2

2

A variation on the OPTIONAL pattern is as follows:

SELECT *
{
  ?person a foaf:Person .
  OPTIONAL { ?person foaf:name      ?x1  }
  OPTIONAL { ?person skos:prefLabel ?x2  }
  OPTIONAL { ?person skos:altLabel  ?x3  }
  OPTIONAL { ?person rdfs:label     ?x4  }
  BIND(COALESCE(?x1, ?x2, ?x3, ?x4) AS ?x)
}

This may be useful if you want to provide a fallback default in the absence of any of the preferred matches being found e.g.

SELECT *
{
  ?person a foaf:Person .
  OPTIONAL { ?person foaf:name      ?x1  }
  OPTIONAL { ?person skos:prefLabel ?x2  }
  OPTIONAL { ?person skos:altLabel  ?x3  }
  OPTIONAL { ?person rdfs:label     ?x4  }
  BIND(COALESCE(?x1, ?x2, ?x3, ?x4, "Unknown") AS ?x)
}

link

answered 31 Jan, 08:04

Rob Vesse ♦
11.8k●6●15
accept rate: 28%

2

Good point about COALESCE to add a default.

Use different variables does mean that the cardinality of each match shows through. The idea of using the same variable is that once found, the later OPTIONALs either match once (single triple, all slots fixed) or don't, so don't change the row count.

(31 Jan, 08:50) AndyS ♦

Yes I did realize that, I suspect your VALUES within a subquery is almost certainly the nicest solution regardless

(31 Jan, 09:34) Rob Vesse ♦

+1 since I think the cardinality issue (i.e., returning multiple values for the preferred predicate) could be a feature not a bug in certain scenarios.

(31 Jan, 12:29) Signified ♦

Answer 3

We find the subjects and properties, with preference numbering. We then check to see there isn't a better match.

Data:

@prefix : <http://example/> .

:s1 :name1 "s11" . :s1 :name2 "s12" .
:s2 :name2 "s22" .
:s3 :name1 "s31" .

Query:

PREFIX :        <http://example/>
SELECT ?x ?p ?o ?pref
{
   VALUES (?p ?pref) { (:name1 10) (:name2 20) }
   ?x ?p ?o
   FILTER NOT EXISTS {
     VALUES (?p2 ?pref2) { (:name1 10) (:name2 20 ) }
     ?x ?p2 ?o2
     FILTER( ?pref2 > ?pref)
   }
} ORDER BY str(?x)

Results:

-------------------------------
| x   | p      | o     | pref |
===============================
| :s1 | :name2 | "s12" | 20   |
| :s2 | :name2 | "s22" | 20   |
| :s3 | :name1 | "s31" | 10   |
-------------------------------

Preference patterns for SPARQL (1.1)

Follow this question

Upcoming Events

Related questions