Experimentar Filosofía para niñ@s en un contexto completamente distinto al que se ha tenido en cuenta hasta ahora en Chile, donde se ha

Query formats within home networking protocols typically take the format ‘Find me an instance of Class X which has attribute Y’. A Class may be a service interface, or an instance of a device adhering to a taxonomy classification. This format can be represented through a format similar to an RDF or OWL statement: (subject, property, object), or in this case (Class X, attribute, Y). To represent this, the Simple Query Interface (SQI) provides a statement-driven interface for querying the ontology registry.

The SQI provides mechanisms for expressing three types of queries:

• Simple Queries: These queries follow a simple (subject, property, object) format.

• Complex Queries: A complex query represents multiple queries over the same subject.

• Meta Queries: A meta-query encapsulates queries which contain sub queries. Using this set of queries, users can interact with the ontology registry, without needing prior understanding of how the information is represented within the reg- istry, or the specific querying mechanisms used by the ontology model. Providing a querying interface also allows the underlying ontology registry to be replaced if required.

The implementation included in this work is designed for interacting with the Jena model. Jena provides a querying language called SPARQL [44], which is de- signed for RDF and OWL information. The implementation converts queries formed using the SQI into SPARQL queries which are specific to the registry implementa- tion. The conversion of the three queries types are implemented in the following manner.

9.3.1 Simple Queries

As mentioned, a Simple Query follows a standard (subject, property, object) format and is represented through the interface as:

public SimpleQuery(String subject, String property, String object) An example Simple Query may be:

new SimpleQuery(‘Device:TV’, ‘Location:hasLocation’, ‘Location:LivingRoom’) ; This query wishes to discover any instances of a TV within the living room. This

query is broken into a SPARQL query which would take on the form: "SELECT ?match " +

"WHERE {?match <Location:hasLocation> <Location:LivingRoom> . ?match <rdfs:SubclassOf> <Device:TV>}" ;

In basic terms, this query requests any classes which match the given pattern, with ?match being used as a wildcard variable. Any classes matching are returned to the SQI in a result set. The SQI then parses this result set, extracts the elements denoted by ?match and then returns this list to the querying client in the form of an array of string URIs. Each URI corresponds to a matching ontology class within the registry.

9.3.2 Complex Queries

Complex Queries are similar to Simple Queries in that they concern a single subject, but may have multiple conditions attached to them. Users can construct Complex Queries using the following interface:

public ComplexQuery(String subject) {

public void addCondition(String property, String object) ; }

String queryString = "SELECT ?match WHERE {";

for (int i = 0; i<query.getConditionSize() ; i++) { Condition condition = query.getCondition(i) ;

queryString += " ?match <"+condition.getProp()+"> <"+condition.getObj()+"> . }" }

queryString += ?match <rdfs:SubclassOf> <"+query.getSubject()+"> }" ;

Figure 9.2: Algorithm for converting Complex Queries ComplexQuery complexQuery = new ComplexQuery(‘Device:TV’) ;

complexQuery.addCondition(‘Location:hasLocation’, ‘Location:LivingRoom’) ; complexQuery.addCondition(‘TV:receivesSignal’, ‘TV:Digital’) ;

This query expands on the Simple Query to discover a TV which can also receive a digital signal. The SQI implementation handles Complex Queries by iterating over the conditions on the query, and adding a new condition to the SPARQL query as demonstrated in Figure 9.2.

Any viable matches are then returned within an array to the querying compo- nent.

9.3.3 Meta Queries

Meta Queries are the mechanism by which clients can submit sub-queries as part of their query. For example, ‘Find me a Lamp device which is located in the room to the left of the Hall’. This method of querying embeds an inner query as the object of the query, allowing clients to query upon unknown information. In this example, the client does not explicitly state what the location of the device should be, but rather indirectly describes the location (as left of the hall).

In this example, the sub-query is an instance of a Simple Query described earlier. Meta Queries can also accept Complex Queries as the object of the query. This would be akin to adding an extra condition onto the object query, which in this case is querying for a location.

Meta Queries can be accessed using the following interfaces:

String queryString = "SELECT ?match WHERE {"; ?meta <Location:toLeftOf> <Location:Hall> . ?meta <rdfs:SubclassOf> <Location:Room> . ?match <Location:hasLocation> ?meta .

?match <rdfs:SubclassOf> <Device:Lamp> }" ;

Figure 9.3: Algorithm behind Meta Queries

Suppose we wanted to form the query given in the above example using a Meta Query. This could be achieved by using the interface in the following manner: SimpleQuery simple = new SimpleQuery(‘Location:Room’,

‘Location:toLeftOf’, ‘Location:Hall’) ;

MetaQuery meta = new MetaQuery(‘Device:Lamp’, ‘Location:hasLocation’, simple) ; SPARQL offers a flexible approach to sub-queries, making use of wildcard vari-

ables. The SQI translates Meta Queries by first separating the query into sub-query parts (i.e into Simple and Complex Queries), and then substituting wildcard vari- ables for unknown classes. For example, the above query would be translated into SPARQL using the sudo-code shown in Figure 9.3.

In this example, ?meta would contain the valid matches for the location part of the query. This variable may hold more than one value, and so the query matches against any Lamps found within any locations matching the location criteria. When submitting Complex Queries as part of a Meta Query, each new condition is added onto the criteria for ?meta. By allowing clients to query over information unknown to them, the number of interactions with the registry is reduced. This also allows clients to remain abstracted from information which they do not directly need.