\chapter{Future Directions}

This work is a solid beginning for future work in Semantic Web based policy assurance. It is also just that: a beginning. There are some important pieces of this project that need to be addressed, and some interesting applications that are just beginning to scratch the surface of what is possible with our reasoner. In this chapter, we discuss future work related to this project in this chapter. This is just a sample of the directions in which this work may grow.

\section{SPARQL Endpoint Integration}

The policy assurance implementation in this paper serves as a standalone component. As we mentioned in the earlier Policy Assurance section, an important future step is to integrate this work with a SPARQL endpoint to demonstrate compliance with incoming queries in real time. To do this, the endpoint would need to be able to look at the AIR reasoner's output, and pull compliance information from that output. A particular endpoint could perform verification using a local or online reasoner, depending on the application specific needs.

\section{SQL Support}

The majority of databases in production use the SQL query language. In order to be compatible with most existing database implementations, our project needs to be able to handle SQL queries. There are several pieces that need to come together for SQL to be a supported language. First, we would need to find a way to translate SQL queries to N3. The SPASQL project (cite) provides for mapping SPARQL queries to SQL. This translation needs more research attention to determine the challenges for converting SQL, or at least a portion thereof to SPARQL. (A conversation with Eric Prud'hommeaux suggests that a one-pass approach may be insufficient, and that this could be a Ph.D. thesis topic.) Secondly, we need a way of describing the fields in a SQL table using URIs.

\section{Completing and Porting the N3 Translator}

The current SPARQL to N3 translation does not support GRAPH, nor does it completely support the built in functions of SPARQL, or nested queries. Furthermore, the current one-pass approach  Instead of a mere re-serialization of the SPARQL query in one pass, it may be necessary to perform additional processing. With more modification to the swobjects code base, multiple pass translation is possible, enabling a much richer translation.

The swobjects approach to query translation was convenient, since the author had easy access to the main developer of swobjects, but it may not be ideal. The majority of the code used in this project, including the reasoner and various scripts, are in Python. The fyzz project \cite{fyzz} implements a SPARQL lexer and parser in Python. This recent project may offer better integration into the rest of the project, allowing a unified query toolkit.

\section{Policy Generation from Natural Language}

Some of Oshani Seneviratne's previous work deals with parsing natural language. It should be possible to parse natural language, or at least a constrained version thereof, in such a way that we could automatically generate policies from that. Using natural language as input would be a great benefit to the usability of this system.

\section{Semantic Policies}

Our collaborators at Lincoln Lab proposed implementing policies which perform reasoning in order to deduce a conclusion. Instead of directly specifying, ``do not allow address searches where CITY equals Boston,'' we can more vaguely specify ``do not allow searches in Boston.'' With an appropriate set of assumptions and data, the reasoner would be able to piece together that Boston contains streets, neighborhoods, ZIP codes, etc. Yotam Aron's work is exploring these possibilities directly, by encoding knowledge bases for the reasoner. A long term goal would be to adapt the reasoner to use existing ontologies in drawing conclusions.

\section{Database Description}

To make things simpler for a user, this project should support loading a database ontology to automatically populate the fields in the policy generation user interface. This reduces duplicated effort, as well as reducing the possibility of simple typographical errors. The database ontology is an N3 description of the attributes in a database, with some pre-defined filters.