# Query1 # This query bears large input and high selectivity. It queries about just one class and # one property and does not assume any hierarchy information or inference. PREFIX rdf: PREFIX ub: SELECT ?X WHERE {?X rdf:type ub:GraduateStudent . ?X ub:takesCourse http://www.Department0.University0.edu/GraduateCourse0} # Query2 # This query increases in complexity: 3 classes and 3 properties are involved. Additionally, # there is a triangular pattern of relationships between the objects involved. PREFIX rdf: PREFIX ub: SELECT ?X, ?Y, ?Z WHERE {?X rdf:type ub:GraduateStudent . ?Y rdf:type ub:University . ?Z rdf:type ub:Department . ?X ub:memberOf ?Z . ?Z ub:subOrganizationOf ?Y . ?X ub:undergraduateDegreeFrom ?Y} # Query3 # This query is similar to Query 1 but class Publication has a wide hierarchy. PREFIX rdf: PREFIX ub: SELECT ?X WHERE {?X rdf:type ub:Publication . ?X ub:publicationAuthor http://www.Department0.University0.edu/AssistantProfessor0} # Query4 # This query has small input and high selectivity. It assumes subClassOf relationship # between Professor and its subclasses. Class Professor has a wide hierarchy. Another # feature is that it queries about multiple properties of a single class. PREFIX rdf: PREFIX ub: SELECT ?X, ?Y1, ?Y2, ?Y3 WHERE {?X rdf:type ub:Professor . ?X ub:worksFor . ?X ub:name ?Y1 . ?X ub:emailAddress ?Y2 . ?X ub:telephone ?Y3} # Query5 # This query assumes subClassOf relationship between Person and its subclasses # and subPropertyOf relationship between memberOf and its subproperties. # Moreover, class Person features a deep and wide hierarchy. PREFIX rdf: PREFIX ub: SELECT ?X WHERE {?X rdf:type ub:Person . ?X ub:memberOf } # Query6 # This query queries about only one class. But it assumes both the explicit # subClassOf relationship between UndergraduateStudent and Student and the # implicit one between GraduateStudent and Student. In addition, it has large # input and low selectivity. PREFIX rdf: PREFIX ub: SELECT ?X WHERE {?X rdf:type ub:Student} # Query7 # This query is similar to Query 6 in terms of class Student but it increases in the # number of classes and properties and its selectivity is high. PREFIX rdf: PREFIX ub: SELECT ?X, ?Y WHERE {?X rdf:type ub:Student . ?Y rdf:type ub:Course . ?X ub:takesCourse ?Y . , ub:teacherOf, ?Y} # Query8 # This query is further more complex than Query 7 by including one more property. PREFIX rdf: PREFIX ub: SELECT ?X, ?Y, ?Z WHERE {?X rdf:type ub:Student . ?Y rdf:type ub:Department . ?X ub:memberOf ?Y . ?Y ub:subOrganizationOf . ?X ub:emailAddress ?Z} # Query9 # Besides the aforementioned features of class Student and the wide hierarchy of # class Faculty, like Query 2, this query is characterized by the most classes and # properties in the query set and there is a triangular pattern of relationships. PREFIX rdf: PREFIX ub: SELECT ?X, ?Y, ?Z WHERE {?X rdf:type ub:Student . ?Y rdf:type ub:Faculty . ?Z rdf:type ub:Course . ?X ub:advisor ?Y . ?Y ub:teacherOf ?Z . ?X ub:takesCourse ?Z} # Query10 # This query differs from Query 6, 7, 8 and 9 in that it only requires the # (implicit) subClassOf relationship between GraduateStudent and Student, i.e., #subClassOf rela-tionship between UndergraduateStudent and Student does not add # to the results. PREFIX rdf: PREFIX ub: SELECT ?X WHERE {?X rdf:type ub:Student . ?X ub:takesCourse } # Query11 # Query 11, 12 and 13 are intended to verify the presence of certain OWL reasoning # capabilities in the system. In this query, property subOrganizationOf is defined # as transitive. Since in the benchmark data, instances of ResearchGroup are stated # as a sub-organization of a Department individual and the later suborganization of # a University individual, inference about the subOrgnizationOf relationship between # instances of ResearchGroup and University is required to answer this query. # Additionally, its input is small. PREFIX rdf: PREFIX ub: SELECT ?X WHERE {?X rdf:type ub:ResearchGroup . ?X ub:subOrganizationOf } # Query12 # The benchmark data do not produce any instances of class Chair. Instead, each # Department individual is linked to the chair professor of that department by # property headOf. Hence this query requires realization, i.e., inference that # that professor is an instance of class Chair because he or she is the head of a # department. Input of this query is small as well. PREFIX rdf: PREFIX ub: SELECT ?X, ?Y WHERE {?X rdf:type ub:Chair . ?Y rdf:type ub:Department . ?X ub:worksFor ?Y . ?Y ub:subOrganizationOf } # Query13 # Property hasAlumnus is defined in the benchmark ontology as the inverse of # property degreeFrom, which has three subproperties: undergraduateDegreeFrom, # mastersDegreeFrom, and doctoralDegreeFrom. The benchmark data state a person as # an alumnus of a university using one of these three subproperties instead of # hasAlumnus. Therefore, this query assumes subPropertyOf relationships between # degreeFrom and its subproperties, and also requires inference about inverseOf. PREFIX rdf: PREFIX ub: SELECT ?X WHERE {?X rdf:type ub:Person . ub:hasAlumnus ?X} # Query14 # This query is the simplest in the test set. This query represents those with large input and low selectivity and does not assume any hierarchy information or inference. PREFIX rdf: PREFIX ub: SELECT ?X WHERE {?X rdf:type ub:UndergraduateStudent}