Supporting Spatial Semantics with SPARQL

1. Supporting Spatial Semantics with SPARQL Dave Kolas, BBN Technologies Terra Cognita 08 Karlsruhe, Germany 10/26/08

2. Presentation Outline • Background Information • What is SPARQL, anyway? • Why does anyone care about spatial semantics? • Related Work • Object-Relational + Spatial • XML + Spatial • Semantic Web + Spatial • Goals of a Spatial Semantic Query Language • What SPARQL can do now • What SPARQL can’t do now • Implementation • Conclusions

3. What is SPARQL, anyway? • SPARQL is the SPARQL Protocol and RDF Query Language • W3C Candidate Recommendation for Semantic Web querying • RDF – Resource Description Framework • Language for describing data on the web • Think XML on steroids • OWL – Web Ontology Language • Language for representing ontologies on the web • Richer than RDF • Builds upon RDF as well

4. Who cares about spatial semantics? • Combining Semantic Web technologies with spatial helps with several important problems • Multiple references to the same place • Multiple names for the same place • Allows complex class and property hierarchies and relationships for representing types • Provides a basis for semantic interoperability

5. Related Work – Object-Relational + Spatial • Not much work to use an Object-Relational query language for querying spatial OR systems • SQL3 – Geometry objects are defined, as well as operations that can be performed on them • This does not provide a transport mechanism for the spatial data!

6. Related Work – XML + Spatial • XML has been used with spatial data to provide a data exchange format and language • Open Geospatial Consortium – GML • Storing data directly in GML is inefficient, difficult to process spatial relationships

7. Related Work – SemWeb + Spatial • Relatively new research area • Provides a higher level of data interoperability with other systems, as formal semantics are defined • Provides more complex relationships than XML can

8. Goals of a Semantic Query Language • Maintain the Graph Theoretical Model of Data • Do not specialize SPARQL for spatial • Support appropriate types of spatial queries • Allow all relevant data to be returned in one query

9. Goals – Maintain the Graph • The fundamental data model of the Semantic Web languages is a conceptual graph • This theoretical model holds from end to end; data is stored as a graph, transferred as a graph, and queried as a graph • Spatial data should not break this paradigm

10. Goals – No Specialized SPARQL for Spatial • A goal of RDF, OWL, and SPARQL is to be domain neutral • No matter what the topic of dicsourse is, you should be able to discuss it in this language • Query clients can be built to create SPARQL queries on the fly • While some clients will obviously know they are querying for spatial data, others may not; these clients should be supported by spatial SPARQL too

11. Goals – Types of Queries • Queries about the spatial properties of an individual • Queries that relate individuals to a known location (point and range queries) • Queries that relate individuals to one another (spatial join, nearest neighbor queries) • Queries that spatially aggregate individuals

12. Goals – All Relevant Data in One Query • One query can be posed for one logical question • Combinations of the query types above must be supported • Spatial data must be retrievable without knowing the geometry types a priori

13. Why not just use functions? • SPARQL already has a mechanism for function calls within a query • Why not just use that? • It breaks the graph model (Goal 1); the relationships then cannot be serialized in the language • It specializes the language (Goal 2); clients have to know they are querying for spatial data

14. What can SPARQL do now? • SPARQL already has the capacity to do basic spatial queries • We can represent geometries ontologically • We can represent spatial relationships ontologically too • DESCRIBE can be used to get spatial information without knowing geometries

15. Current SPARQL – Representing Geometries • We can use an ontology of geometries so that geometry definitions can be put directly in the query! • Base this on GML geometry types, using W3C Geo language [] a restaurant:PizzaParlor; restaurant:name “Jimmy’s Pizza”; georss:where [ a gml:Point; gml:pos “38 -77” ].

16. Current SPARQL – Representing Relationships • We can use an ontology of topological relationships so that they too can be put in the query! • Base this on some formalism (here, RCC8*): rcc:disconnected a owl:ObjectProperty ; a owl:SymmetricProperty . rcc:part a owl:ObjectProperty ; rdfs:subPropertyOf rcc:connected . * We use the terms from RCC8 without necessarily using the reasoning axioms

17. Current SPARQL – Using Describe • DESCRIBE is a query mechanism whereby a querier can request unspecified data about an object; what is returned is up to the knowledge service • A spatial knowledge base can use this functionality to return geometry infromation, whether it is in the form of a point, line, polygon, etc. DESCRIBE ?geo WHERE { <http://data/#JimmysPizza> georss:where ?geo }

18. What does SPARQL need? • There are some things that are awkward or just cannot be done with the current specification. • Range queries are awkward • Getting back geometry types is challenging • Count queries are impossible

19. Enhancements – Query Premise • Concept is that querier declares statements to be true to be considered with the query • Query premises have been used in several other languages • KQML • DAML-QL • Query premises allow us to cleanly express range queries

20. Query Premise – Example SELECT ?x PREMISE { ?b a gml:Buffer; gml:radius “1”; gml:bufferGeometry [ a gml:Point; gml:pos “38 -77” ]. } WHERE { ?x a gas:GasStation; georss:where ?y. ?y rcc:part ?b . }

21. Enhancements – Embedded Describe • The problem is that it is complex to ask for things within a spatial region and get their geometries in the same query • Can be done, but needs to use series of OPTIONAL clauses (UGLY) • If we could use the DESCRIBE functionality within other types of queries, we could do it!

22. Embedded Describe - Example SELECT ?landmark ?geometry DESCRIBE(?geometry) WHERE { ?landmark a lm:LandMark; georss:where ?geometry. ?geometry a ?geometryType; rcc:part ?x. va-counties:Arlington georss:where ?x. }

23. Enhancements – Counting • Maybe surprisingly, SPARQL cannot count! • This is due to the lack of a unique names assumption • But we need to count, and sometimes we know we can count • When two things returned *must* be unique! • Potential solution: count references instead of individuals

24. Counting – Example SELECT COUNT(?x) PREMISE { ?b a gml:Buffer; gml:radius “1”; gml:bufferGeometry <http://data/#JimmysLocation> } WHERE { ?x a restaurant:PizzaParlor; georss:where [ rcc:part ?b ] . }

25. Implementation • BBN has developed a prototype knowledgebase for combining Semantic Web data with spatial data, temporal data, and indexing of both • This KB makes use of the Spatial SPARQL suggestions outlined here • There are also extensions to the Lehigh University Benchmark based on this work, for testing scalability of spatial Semantic Web knowledge bases

26. Conclusions • SPARQL can already be used for basic querying of spatial semantic systems! • Several enhancements can be added to SPARQL that support spatial data while also being generally useful: • Query Premises • Embedded DESCRIBE • Counting

27. Questions?