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

Presentation Outline 2 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

What is SPARQL, anyway? 3 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

Who cares about spatial semantics? 4 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

Related Work – Object-Relational + Spatial 5 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!

Related Work – XML + Spatial 6 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

Related Work – SemWeb + Spatial 7 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

Goals of a Semantic Query Language 8 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

Goals – Maintain the Graph 9 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

Goals – No Specialized SPARQL for Spatial 10 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

Goals – Types of Queries 11 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

Goals – All Relevant Data in One Query 12 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

Why not just use functions? 13 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

What can SPARQL do now? 14 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

Current SPARQL – Representing Geometries 15 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” ].

Current SPARQL – Representing Relationships 16 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

Current SPARQL – Using Describe 17 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 { georss:where ?geo }

What does SPARQL need? 18 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

Enhancements – Query Premise 19 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

Query Premise – Example 20 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. }

Enhancements – Embedded Describe 21 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!

Embedded Describe - Example 22 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. }

Enhancements – Counting 23 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

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

Implementation 25 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

Conclusions 26 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

Questions? 27