SPARQL with Qualitative & Quantitative Preferences

SPARQL with Qualitative & Quantitative Preferences Marina Gueroussova Axel Polleres* Sheila A. McIlraith Department of Computer Science, University of Toronto * Vienna University of Economics and Business (WU Wien), Contact: @AxelPolleres OrdRing2013 October 21, 2013

Motivation SPARQL Data: • Massive • Produced, shared, consumed by diversity of stakeholders • Dynamically integrated • Scope of content often unknown: Queries can lead to the “empty result effect” (no answer) and its opposite “flooding effect” (too many answers), resulting in a time consuming and frustrating manual/iterative search Consider searching for a car to buy – one might prefer a car with a powerful engine, but only if it’s a hybrid, or failing that an electric car if it’s under a certain price … ideally silver, rear camera, but these are less important … Preferences!

Challenge: How do we specify and generate preference-based queries in SPARQL

Rich Literature Preferences have been long studies across many fields including economics, philosophy, and computer science. Databases (preferences in relational queries & SQL, top-K), e.g. : • Chomicki (2002,2003,2011) • Kießling, Endres &Wenzel (2011) , Kießling&Köstler (2002), Kießling (2002), AI (decision theory in AI, CP nets, preference-based planning), e.g.: • Domshlak, Hullermeier, Kaci & Prade (2011) • Boutilier, Brafman, Domshlak, Hoos & Poole (2004) Semantic Web & Linked Data (top-k, qualitative preferences), e.g.: • Siberski, Pan & Thaden (2006) • Wagner, Tran, Ladwig, Harth & Studer (2012) • Magliacane, Bozzon & Della Valle (2011, 2012)

Contributions • Extend SPARQL Syntax to handle qualitative and quantitative preferences queries • Demonstrate that qualitative and conditional preferences can be natively expressed in SPARQL (both 1.0 and 1.1) • Illustrate how queries can be rewritten into standard compliant SPARQL queries via filtering. (Contrary to an earlier conjecture predicated on a less expressive SPARQL.) • Discuss avenues for future work

Outline • Example • PrefSPARQL Grammar • Query Rewriting • Future Work

Tue Example * day starts end day starts end day starts end day starts end day starts end <#appointmt1> 1500 1555 offers Sun <#appointmt2> <#mary> offers 1600 1655 rated offers Sun excellent <#appointmt3> 1600 1655 very-good Sat <#appointmt4> 1800 rated offers 1855 <#john> Mon offers <#appointmt5> 1900 * Modified from [Siberski et al., 2006] 1955

Example (cont.) :mary a :therapist ; :rated :excellent ; :offers :appointmt1, :appointmt2, :appointmt3 . :john a :therapist ; :rated :very-good ; :offers :appointmt4, :appointmt5 . :appointmt1 :day "Tue"; :starts 1500; :ends 1555. :appointmt2 :day "Sun"; :starts 1600; :ends 1655. :appointmt3 :day "Fri"; :starts 1700; :ends 1755. :appointmt4 :day "Sat"; :starts 1800; :ends 1855. :appointmt5 :day "Mon"; :starts 1900; :ends 1955.

Example Queries QUERY 1: Return all therapist appointments with the following preferences: Prefer excellent therapists. Prefer appointments around lunchtime (between 12:00 and 13:00). Prefer later appointments over earlier ones provided that both are equal with respect to lunchtime. This is a so-called skyline query that returns an undominated solution. QUERY 2: Return all appointments with the following preferences: Prefer appointments before 6pm on weekends (Sat & Sun) and appointments after 6pm on weekdays.

How do we specify preference-based queries in SPARQL?

PrefSPARQL Grammar Filter ::= 'FILTER' Constraint | 'PREFERRING' '(' MultidimensionalPref ')' MultidimensionalPref ::= PrioritizedPref ('AND' PrioritizedPref)* PrioritizedPref ::= ConditionalOrAtomicPref ('PRIOR TO' ConditionalOrAtomicPref)* ConditionalOrAtomicPref ::= ConditionalPref | AtomicPref ConditionalPref ::= 'IF' Expression 'THEN' ConditionalOrAtomicPref 'ELSE' ConditionalOrAtomicPref AtomicPref ::= Expression | HighestPref | LowestPref | BetweenPref | AroundPref | MoreThanPref | LessThanPref HighestPref ::= 'HIGHEST' Expression LowestPref ::= 'LOWEST' Expression BetweenPref ::= Expression 'BETWEEN' '(' Expression ',' Expression ')' AroundPref ::= Expression 'AROUND' Expression MoreThanPref ::= Expression 'MORE THAN' Expression LessThanPref ::= Expression 'LESS THAN' Expression

PrefSPARQL Grammar (Query 1) … PrioritizedPref ::= ConditionalOrAtomicPref ('PRIOR TO' ConditionalOrAtomicPref)* ConditionalOrAtomicPref ::= ConditionalPref | AtomicPref … AtomicPref ::= Expression | HighestPref | LowestPref | BetweenPref | AroundPref | MoreThanPref | LessThanPref … BetweenPref ::= Expression 'BETWEEN' '(' Expression ',' Expression ')' AroundPref ::= Expression 'AROUND' Expression … SELECT ?A WHERE { ?T :rated ?R; offers ?A. ?A starts ?S; :end ?E. PREFFERING { ?R = excellent AND { ?S BETWEEN(1200,1300) AND ?E BETWEEN{1200,1300) PRIOR TO HIGHEST ?E } } }

PrefSPARQL Grammar (Query 2) … ConditionalOrAtomicPref ::= ConditionalPref | AtomicPref ConditionalPref ::= 'IF' Expression 'THEN' ConditionalOrAtomicPref 'ELSE' ConditionalOrAtomicPref … SELECT ?A WHERE { ?A :day ?D; :starts ?S. PREFERRING ( IF (?D = "Sat" || ?D = "Sun") THEN ?S < 1800 ELSE ?S >= 1800 ) }

Outline • Example • PrefSPARQL Grammar • Query Rewriting • Future Work

How do we generate preference-based queries using SPARQL query engines?

Approach • [Siberski et al. 2006] realized a subset of qualitative preferences in SPARQL using solution modifiers. • It’s easy to imagine how to realize at least some of these references using “stacked optionals”. • Contrary to the conjecture* in [Sibserski et al. 2006], we argue that our PrefSPARQL queries can be expressed in SPARQL by the following high-level translation schema in SPARQL 1.1 **: * Made in 2006, prior to the addition of OPTIONAL to SPARQL ** There is a corresponding translation schema for SPARQL 1.0 P PREFERRING Pref P FILTER NOT EXISTS {P’FILTER (tr(P, P’, Pref))}

Rewriting (simplified version of) Query 1 SELECT ?A WHERE { ?T :rated ?R; :offers ?A. ?A :starts ?S; :ends ?E . PREFERRING ( (?R = excellent) AND ((?S >= 1800) || ?E <= 1600) PRIOR TO HIGHEST ?S ))} SELECT ?A WHERE { ?T :rated ?R; :offers ?A. ?A :starts ?S; :ends ?E . BIND ( (?R = :excellent) AS ?Pref1 ) BIND ( (?S >= 1800 || ?E <= 1600) AS ?Pref2 ) BIND ( ?S AS ?Pref3 ) FILTER NOT EXISTS { ?T_ :rated ?R_; :offers ?A_. ?A_ :starts ?S_; :ends ?E_ . BIND ( (?R_ = :excellent) AS ?Pref1_ ) BIND ( (?S_ >= 1600 || ?E_ <= 1600) AS ?Pref2_ ) BIND ( ?S_ AS ?Pref3_ ) FILTER( ( (?Pref1_ > ?Pref1) && !((?Pref2_ < ?Pref2) || (?Pref3_ < ?Pref3 && ?Pref2 = ?Pref2_ ))) || ( !(?Pref1_ < ?Pref1) && ((?Pref2_ > ?Pref2) || (?Pref3_ > ?Pref3 && ?Pref2 = ?Pref2_ ))))}} P PREFERRING Pref P FILTER NOT EXISTS {P’FILTER (tr(P, P’, Pref))}

Rewriting (simplified version of) Query 1 SELECT ?A WHERE { ?T :rated ?R; :offers ?A. ?A :starts ?S; :ends ?E . PREFERRING ( (?R = excellent) AND ((?S >= 1800) || ?E <= 1600) PRIOR TO HIGHEST ?S ))} SELECT ?A WHERE { ?T :rated ?R; :offers ?A. ?A :starts ?S; :ends ?E . BIND ( (?R = :excellent) AS ?Pref1 ) BIND ( (?S >= 1800 || ?E <= 1600) AS ?Pref2 ) BIND ( ?S AS ?Pref3 ) FILTER NOT EXISTS { ?T_ :rated ?R_; :offers ?A_. ?A_ :starts ?S_; :ends ?E_ . BIND ( (?R_ = :excellent) AS ?Pref1_ ) BIND ( (?S_ >= 1600 || ?E_ <= 1600) AS ?Pref2_ ) BIND ( ?S_ AS ?Pref3_ ) FILTER( ( (?Pref1_ > ?Pref1) && !((?Pref2_ < ?Pref2) || (?Pref3_ < ?Pref3 && ?Pref2 = ?Pref2_ ))) || ( !(?Pref1_ < ?Pref1) && ((?Pref2_ > ?Pref2) || (?Pref3_ > ?Pref3 && ?Pref2 = ?Pref2_ ))))}} tr(P,P’,Pref1 AND Pref23) (Pref1’ > Pref1 && Pref23’ < Pref23) || (Pref1’ < Pref1 && Pref23’ > Pref23 )

Rewriting (simplified version of) Query 1 SELECT ?A WHERE { ?T :rated ?R; :offers ?A. ?A :starts ?S; :ends ?E . PREFERRING ( (?R = excellent) AND ((?S >= 1800) || ?E <= 1600) PRIOR TO HIGHEST ?S ))} SELECT ?A WHERE { ?T :rated ?R; :offers ?A. ?A :starts ?S; :ends ?E . BIND ( (?R = :excellent) AS ?Pref1 ) BIND ( (?S >= 1800 || ?E <= 1600) AS ?Pref2 ) BIND ( ?S AS ?Pref3 ) FILTER NOT EXISTS { ?T_ :rated ?R_; :offers ?A_. ?A_ :starts ?S_; :ends ?E_ . BIND ( (?R_ = :excellent) AS ?Pref1_ ) BIND ( (?S_ >= 1600 || ?E_ <= 1600) AS ?Pref2_ ) BIND ( ?S_ AS ?Pref3_ ) FILTER( ( (?Pref1_ > ?Pref1) && !((?Pref2_ < ?Pref2) || (?Pref3_ < ?Pref3 && ?Pref2 = ?Pref2_ ))) || ( !(?Pref1_ < ?Pref1) && ((?Pref2_ > ?Pref2) || (?Pref3_ > ?Pref3 && ?Pref2 = ?Pref2_ ))))}} tr(P,P’,Pref2 PRIOR TO Pref3) (Pref2’ > Pref2) || (Pref3’ > Pref3 && Pref2’ = Pref2 )

Rewriting (simplified version of) Query 1 SELECT ?A WHERE { ?T :rated ?R; :offers ?A. ?A :starts ?S; :ends ?E . PREFERRING ( (?R = excellent) AND ((?S >= 1800) || ?E <= 1600) PRIOR TO HIGHEST ?S ))} SELECT ?A WHERE { ?T :rated ?R; :offers ?A. ?A :starts ?S; :ends ?E . BIND ( (?R = :excellent) AS ?Pref1 ) BIND ( (?S >= 1800 || ?E <= 1600) AS ?Pref2 ) BIND ( ?S AS ?Pref3 ) FILTER NOT EXISTS { ?T_ :rated ?R_; :offers ?A_. ?A_ :starts ?S_; :ends ?E_ . BIND ( (?R_ = :excellent) AS ?Pref1_ ) BIND ( (?S_ >= 1600 || ?E_ <= 1600) AS ?Pref2_ ) BIND ( ?S_ AS ?Pref3_ ) FILTER( ( (?Pref1_ > ?Pref1) && !((?Pref2_ < ?Pref2) || (?Pref3_ < ?Pref3 && ?Pref2 = ?Pref2_ ))) || ( !(?Pref1_ < ?Pref1) && ((?Pref2_ > ?Pref2) || (?Pref3_ > ?Pref3 && ?Pref2 = ?Pref2_ ))))}} FILTER NOT EXISTS canbeemulated in SPARQL1.0 with OPTIONAL + FILTER( !bound(...) )  expressible in SPARQL1.0!! P PREFERRING Pref P FILTER NOT EXISTS {P’FILTER (tr(P, P’, Pref))}

Rewriting Query 2 (conditional preferences) SELECT ?A WHERE { ?A :day ?D; :starts ?S. PREFERRING ( IF (?D = "Sat" || ?D = "Sun") THEN ?S < 1800 ELSE ?S >= 1800 ) } IF E THEN Pref1 ELSE Pref2) IF(E, Pref1, Pref2) SELECT ?A WHERE { ?A :day ?D; :starts ?S. BIND ( IF( (?D = "Sunday" || ?D = "Saturday"), ?S < 1800, ?S >= 1800) AS ?Pref1) FILTER NOT EXISTS { ?T_ :rated ?R_; :offers ?A_. ?A_ :day ?D_; :starts ?S_. BIND ( IF( (?D_ = "Sunday" || ?D_ = "Saturday"), ?S_ < 1800, ?S_ >= 1800) AS ?Pref1_) FILTER (?Pref1_ > ?Pref1)}} Again: FILTER NOT EXISTS canbeemulated in SPARQL1.0 with OPTIONAL + FILTER( !bound(...) )  expressible in SPARQL1.0!!

Observe that these queries (use of NOT EXISTS, i.e. OPTIONAL+!bound()) yield non-well-designed patterns [Perez et al., 2009], [Letelier et al., 2012]. Cost of rewriting? Similar to well-known trick in in SPARQL to express preferences by simply “stacking optionals”…… which is also non-well-designed SELECT ?Contact WHERE { me foaf:knows ?X OPTIONAL {?X foaf:mbox ?Contact} OPTIONAL {?X foaf:homepage ?Contact} }

Summary of Contributions • Extend SPARQL Syntax to handle qualitative and quantitative preferences queries • Demonstrate that qualitative and conditional preferences can be natively expressed in SPARQL (both 1.0 and 1.1) • Illustrate how queries can be rewritten into standard compliant SPARQL queries via filtering. (Contrary to an earlier conjecture predicated on a less expressive version of SPARQL.)

Ongoing Work • Experimental evaluation of the efficacy of the rewriting approach proposed here. • Further investigation of relaxation of the well-designedness principle, which will enable efficient preference query evaluation. • Expanding scope to (better) deal with: • Top-k queries • Ranking within skyline queries • Preferences over endpoints w/ SPARQL 1.1 Fedration extension • Express SPARQL endpoint preference (SERVICE patterns) • Interactions between preferences and Entailment Regimes [Glimm et al. 2013]

Want to know more? SPARQL with Qualitative and Quantitative Preferences (Extended Report) . Marina Gueroussova, Axel Polleres, Sheila A. McIlraith. Technical Report CSRG-619, Department of Computer Science, University of Toronto (October 2013). ftp://ftp.cs.toronto.edu/csrg-technical-reports/619/

References • Craig Boutilier, Ronen I. Brafman, Carmel Domshlak, Holger H. Hoos, David Poole: CP-nets: A Tool for Representing and Reasoning with Conditional Ceteris Paribus Preference StatementsJ. Artif. Intell. Res.(JAIR) 21, 135-191 (2004). • Jan Chomicki: Querying with Intrinsic Preferences. EDBT 2002: 34-51 (2002) • Jan Chomicki: Preference formulas in relational queries. ACM Trans. Database Syst. 28(4): 427-466 (2003) • Jan Chomicki: Logical Foundations of Preference Queries. IEEE Data Eng. Bull. 34(2): 3-10 (2011) • Carmel Domshlak, Eyke Hüllermeier, Souhila Kaci, Henri Prade: Preferences in AI: An overview. Artif. Intell. 175(7-8): 1037-1052 (2011) • Werner Kießling: Foundations of Preferences in Database Systems. VLDB 2002: 311-322 (2002) • Werner Kießling, Markus Endres, Florian Wenzel: The Preference SQL System - An Overview. IEEE Data Eng. Bull. 34(2): 11-18 (2011) • Werner Kießling, Gerhard Köstler: Preference SQL - Design, Implementation, Experiences. VLDB 2002: 990-1001 (2002) • Andrés Letelier, Jorge Pérez, Reinhard Pichler, Sebastian Skritek: Static analysis and optimization of semantic web queries. PODS 2012: 89-100 (2012) • Sara Magliacane, Alessandro Bozzon, Emanuele Della Valle: Efficient Execution of Top-K SPARQL Queries. International Semantic Web Conference (1) 2012: 344-360 (2012) • Jorge Pérez, Marcelo Arenas, Claudio Gutierrez: Semantics and complexity of SPARQL. ACM Trans. Database Syst. 34(3) (2009) • Wolf Siberski, Jeff Z. Pan, Uwe Thaden: Querying the Semantic Web with Preferences. International Semantic Web Conference 2006: 612-624 (2006) • Kostas Stefanidis, Georgia Koutrika, Evaggelia Pitoura: A survey on representation, composition and application of preferences in database systems. ACM Trans. Database Syst. 36(3): 19 (2011) • Andreas Wagner, Duc Thanh Tran, Günter Ladwig, Andreas Harth, Rudi Studer: Top-k Linked Data Query Processing. ESWC 2012: 56-71 (2012)

Thank You. Questions?

SPARQL with Qualitative & Quantitative Preferences