Some recent works on natural language semantic parsing make use of syntax and semantics together using di erent combination models. In our work we attempt to use SPARQL-DL as an interface between syntactic information given by the Stanford statistical parser (namely part-of-speech tagged text and typed dependency representation) and semantic information obtained from the FrameNet database. We use SPARQL-DL queries to check the presence of syntactic patterns within a sentence and identify their role as frame elements. The choice of SPARQL-DL is due to its usage as a common reference language for semantic applications and its high expressivity, which let rules to be generalized exploiting the inference capabilities of the underlying reasoner.
The tools available nowadays for natural language processing can achieve very
good results on many complex tasks such as the parsing of a sentence. The
limitations of such tools are in the richness of their output: the Stanford parser1,
for example, can produce a parse tree, a POS tagging and a dependency graph,
but it does not provide any clues about the meaning and the topic nor it uses any
semantic information to check that the sentence is semantically correct. On the
other hand, projects such as FrameNet [
Several approaches have been proposed to bridge the gap, using probabilistic
models [
The paper is organized as follows: in Section 2 we describe the sources of information we use; in Section 3 we describe the mapping between the di erent sources, while in Section 4 we show the whole process of a sentence analysis; in Section 5 we summarize our work and propose some future extensions.
The Stanford parser can provide several types of output, such as part-of-speech
(POS) tagging [
The most important role within FrameNet is played by lexical units (LUs), which can be considered as \frame-evoking words" in the sense that they are used within an event or situation captured by a frame, having a speci c role and meaning; for instance, the LU like.v is related to the use of the verb to like within the frame Experiencer focus (it only appears in one frame). Every LU, which usually is a verb, comes in a variety of di erent syntactic realizations (SRs), which means that it can be used in di erent ways within a sentence depending on its role and form (e.g., I like apples and I like climbing mountains). Every type of realization is presented as a valence pattern, a combination of concepts pertaining to the frame called frame elements (FEs) such as Experiencer, Reason and Content, associated to syntactic realizations.
An example of valence pattern from FrameNet is: where the subscripts are the FEs and the words separated by a dot are called respectively phrase type (PT ) and grammatical function (GF ), capturing respectively the \shape" and the function of a speci c FE in a sentence. In the previous example, the sentence tagged with frame elements would be: [I]Experiencer like [him]Content [as a fellow]P arameter.
For the lexical unit like.v, other examples of valence patterns would be:
[I]Experiencer like [the rounds]Content [for their versatility]Reason
[This man]Content was [very much]Degree liked [by the Masai]Experiencer A phrase type such as PP[at], for example, means that the corresponding FE should be a phrase containing a preposition (in this case at ); a grammatical function such as Obj, instead, means that the corresponding FE has an object function according to FrameNet speci cation (i.e. not necessarily according to its syntactic position within the sentence). In our approach, we always use these two descriptors together as a pair. 3 3.1
First of all, the sentence to analyze is converted to a temporary ontology where
the individuals are the words in the sentence along with their position, a datatype
property called lemma is the word itself in its base form, the classes are the
POS tags and the roles are the dependency types; we use a pre-de ned ontology
containing all the possible POS tags and dependency types as they have been
de ned in the related papers (see [
ObjectProperty(like-2, nsubj, I-1) ObjectProperty(ROOT-0, root, like-2) ObjectProperty(like-2, dobj, him-3) ObjectProperty(like-2, prep, as-4) ObjectProperty(fellow-6, det, a-5)
ObjectProperty(as-4, pobj, fellow-6) ObjectProperty(VBP, nsubj, PRP) ObjectProperty(VBP, dobj, PRP) ObjectProperty(NN, det, DT) ObjectProperty(ROOT, root, VBP) ObjectProperty(VBP, prep, IN) ObjectProperty(IN, pobj, NN) Now we can select the object properties containing only the words tagged as PP[as].Dep, thus obtaining a rule stating that a PP[as].Dep pair is characterized by the presence of the roles: ObjectProperty(VBP, prep, IN) ObjectProperty(IN, pobj, NN) where the individual belonging to the class IN (in this case as-4) must have the string as as the value of the datatype property lemma(this is useful because the Stanford parser associates most of the prepositions with the same POS tag IN). The pattern given above can be used to check whether a sentence contains the given <PT, GF> pair (and, consequently, its related FE). In the ontology of POS tags and roles we have de ned a taxonomy of POS tags as well, so rules can be easily generalized using a reasoner; in the example above the class VBP (a verb in non-3rd person singular present) is actually a subclass of VB (a verb in its base form), so the rst relation can be replaced by ObjectProperty(VB, prep, IN) (if the presence of a verb in non-3rd person singular present is found not to be mandatory for the speci c pattern). This approach is especially useful when no rules matching a sentence can be found, in that it makes it possible to loosen some constraints (e.g., it makes it possible to look for a verb in its base form when a verb in the 3rd person form is expected). 3.2
In order to match a pattern in a sentence, we represent it as a SPARQL-DL query. For example, the pattern
can be represented by the SPARQL-DL query PREFIX : <ontology prefix> SELECT ?n1 ?n2 ?n3 WHERE f Type(?n1, :VB), Type(?n2, :IN), Type(?n3, :NN), PropertyValue(?n1, :prep, ?n2), PropertyValue(?n2, :pobj, ?n3),
PropertyValue(?n2, :lemma, "as") g
The reason why we use SPARQL-DL to perform queries relies, as we have anticipated, on its intrinsic use of the reasoner: the query above will match all the forms of a verb and all the types of noun (singular, mass, plural, proper). Every query contains some additional information such as the name of the represented <PT, GF> pair, the number of matches over the whole database etc. The SPARQL-DL implementation we are using relies on the OWL API and covers all of OWL 2.
The same procedure is applied for all the pairs <PT, GF> present in the FrameNet database, with every query having as the rst bound variable the verb evoked by the related LU (we cannot show here other examples because of space limits). In order to derive the queries, we make some hypotheses: { every SR pair <PT, GF> is independent from the verbs it is used with, which means that it makes sense to talk of a \general" pair (e.g. PP[by].Dep for like has the same realization for tell in the sentences I am liked by her and I was told by him); { we exclude the cases of null instantiation, where a frame element is not represented by any word in the sentence (e.g., in the sentence Molly rarely eats alone the verb eat is used intransitively while it is usually expected to have an object).
The queries are then built in a semi-automatic manner: 1. the pair <PT, GF> to analyze (e.g. PP[as].Dep) is chosen; 2. a search in FrameNet is performed to nd all the examples of sentences whose SR contains a PP[as].Dep element (and whose related LU is a verb); 3. an example sentence is selected and parsed; 4. the elements tagged with the chosen pair are selected and shown together with their typed dependencies; 5. a SPARQL-DL query matching such dependencies is written by hand; 6. the obtained query is checked on all the previously found example sentences to nd the number of matches; 7. the procedure is repeated to increase the matches or to extract a query for a di erent pair.
We opted out for such approach because of several limitations in the FrameNet data: { some sentences cannot be used as examples either because they are misspelt (thus causing parsing errors) or because the parser provides wrong POS tags (e.g. a verb in -ing form tagged as an adjective); { in some sentences a chunk which is tagged with a single FE can be very long, so it can be matched by several queries related to di erent FEs; { it is not always trivial to decide which is the head word in a tagged FE within a sentence, especially in the case of long chunks; { FrameNet is not a statistically representative resource. 4
After the preparation process, the steps which are performed to analyze and semantically parse a sentence are: 1. parsing of the sentence to obtain the POS tags, the dependency graph and the verbs; 2. conversion of the sentence in a temporary ontology; 3. execution of all the available queries and collection of all the results; 4. extraction of the valence patterns for all the frames related to the verbs; 5. check of the matching valence patterns; 6. tagging of the sentence elements with the found FEs.
The match of a valence pattern is performed by rst selecting only the satis ed queries whose rst bound variable (the verb in its base form) is the same one of the considered LU. Some patterns have multiple FEs with the same syntactic realization within the same pattern; this is usually not a problem as they also have the same semantic tag. To help the use and retrieval of the shape of the valence patterns, we built an ontology of FrameNet syntactic realizations; di erently from other ontologies related to the same domain, our ontology contains all the syntactic realizations for every frame related to each verb. This makes it easy and unambigous to derive the possible syntactic realizations for a frame without the need of having the whole FrameNet database (to which it is anyway linked by links to the XML les containing the related LUs).
As an example of the use of this procedure we considered the like.v LU. The verb like is regular, so its base form can be easily retrieved; anyway, as we will see in the last section, this condition is not restrictive. The queries we are using are not exhaustive, meaning that they do not cover all the possible syntactic realizations.
Going back to the previous example, the queries matching the sentence I like him as a fellow are the ones associated to the pairs AVP.Dep, NP.Ext, NP.Obj and PP[as].Dep; as there are no other verbs in the sentence, all of them are selected. The valence patterns which are found to match this set of results are
and
In this case the reason of the ambiguity is given by the inclusion of the second valence pattern in the rst one. After nding the matching valence patterns, the sentence is tagged accordingly; currently we only tag the head words (and the words following a preposition, in the case of prepositional phrases), so in the rst case we would obtain: [I]Experiencer like [him]Content [as fellow]P arameter.
We ran this analysis on all the example sentences within the like.v LU, and the results we obtained show a greater di culty in retrieving FEs whose syntactic realization is NP.Obj (noun phrase used as object), NP.Ext (noun phrase used as external argument) and AVP.Dep (adverb phrase); this is due mostly to the high variability in syntactic realizations (or, equivalently, to its ambiguous de nition), while in prepositional phrases the prepositions act as anchors. In general, at this stage of the work, the failure rate in recognizing a FE goes between 10% and 50% (for the most di cult elements). Some more examples of results are: I quite like nursery rows sometimes. [I]Experiencer [quite]Degree like [rows]Content [sometimes]Degree Would you like cheese in your sandwich? Would [you]Experiencer like [cheese]Content [in sandwich]Content The average time for the whole analysis on a modern laptop (Intel R CoreTMi7 2.00 GHz, 4 GB of RAM) is about 0.22 seconds.
We still have not run our analysis on databases other than FrameNet because there are no ones having comparable annotations; anyway, as an example of the errors which can be revealed by such approach, the sentence You like this don't you? could not be tagged because of the missing comma between this and don't, which makes the parser give a wrong output. 5
In this work we have shown an application of SPARQL-DL query language to natural language processing, more speci cally as a rule engine to use within a semantic parser. We have shown that the use of such formalism for this task has several advantages such as the straightforward conversion of a typed dependency graph in an ontology, the clarity of the queries (which can be written in a standard way instead of being de ned using a custom language) and their generality (due to the use of a reasoner).
We are currently investigating the use of statistic measures to help in the disambiguation, that is when more than one pattern match the same sentence; our approach includes the use of the frequencies of each pattern and the probability for each FE within a pattern to have a certain position within the pattern itself. Also, we are adopting a lemmatizer to retrieve the base form of verbs after they have been found in the analyzed sentence; this lets it possible to deal with irregular verbs.
As future extensions we plan to add a semantic expansion/disambiguation module, in order both to cope with synonyms which are not explicitly present in the FrameNet database and to deal with semantically wrong sentences (e.g. to put in evidence problems in sentences like I ride a pencil when the pencil is not a rideable object); several authors use other databases such as WordNet and VerbNet, while we are planning to use OpenCyc as well. Another extension is related to a fully automatic generation of the queries to use as matching rules: there are several problems to be solved, mainly depending on the ambiguity of the tags which make it di cult to automatically derive the head word of every FE, and on parsing or typing errors.