1 Introduction

Sentiment analysis is now an established field of research and a growing industry [1]. However, language resources for sentiment analysis are being developed by individual companies or research organizations and are normally not shared, with the exception of a few publicly available resources such as WordNet-Affect [2] and SentiWordNet [3].

Domain-specific resources for multiple languages are potentially valuable but not shared, sometimes because of intellectual property and license considerations, but often because of technical reasons, including interoperability. Several initiatives have addressed interoperability of language resources since the late 1980s, such as Text Encoding Initiative [4], but there is not yet a widely accepted global solution for integrating and combining heterogeneous linguistic resources from different sources [5]. In this respect the data interoperability problem has been addressed by linked data technologies, which have gained wide acceptance. Linked data [6] refers to best practices and technologies for publishing, sharing, and connecting structured data on the web. This approach has been followed by the linking open data (LOD) project, a grassroots community effort supported by the World Wide Web Consortium (W3C) whose aim is to bootstrap the Web of Data by identifying existing datasets available under open licenses, converting them to Resource Description Framework (RDF) format following the linked data principles, and publishing them on the web. The data cloud that originated from this initiative is known as the LOD cloud. Several communities such as the Open Linguistics Working Group [5] proposed the idea of adopting linked data principles for representing, sharing, and publishing open linguistic resources with the aim of developing a subcloud of the LOD cloud of linguistic resources, known as the linguistic linked open data (LLOD) cloud [7].

In addition, the use of linked data for modeling linguistic resources provides a clear path to their semantic annotation and linking with semantic resources of the Web of Data. This is especially important for making sense of social media streams, whose semantic interpretation is particularly challenging because they are strongly interconnected, temporal, noisy, short, and full of slang [8]. Moreover, several authors [9] have shown that the use of semantics in sentiment analysis outperforms semantics-free methods. Thus the availability of semantically annotated linguistic resources is crucial to the development of the field of sentiment analysis.

This chapter presents our contribution to the development of the sentiment LLOD cloud through a linked data model for sentiment and emotion analysis in social networks that is based on two vocabularies: Marl and Onyx for sentiment and emotion modeling respectively as described in Sections 2 and 3. The rest of the chapter illustrates how these vocabularies are used for annotation of sentiment language resources as well as services (Fig. 4.1). Section 4 describes the generation of a sentiment-linked data corpus based on the use of Marl, Onyx, and Natural Language Processing Interchange Format (NIF), which allows the representation of text with unique URLs. Section 5 describes how sentiment lexicons can be expressed with Marl, Onyx, and the Lexicon Model for Ontologies (lemon), which provides lexical information and differentiates between different domains and senses of a word. Section 6 introduces sentiment analysis interoperability through the use of a Representational State Transfer NIF application programming interface in combination with Marl and Onyx. Section 7 illustrates the benefits of this linguistic linked data approach in the generation of a domain-specific sentiment lexicon on a big linked data platform. Finally, we present our conclusions in Section 8.

2 Marl: A Vocabulary for Sentiment Annotation

The Marl ontology [10, 11] is a vocabulary designed for annotation and description of subjective opinions expressed in text. The goals of the Marl ontology are to (1) enable the publishing of raw data on opinions and the sentiments, (2) deliver schema that will allow opinions coming from different systems (polarity, topics, and features) to be compared, and (3) interconnect opinions by linking them to contextual information expressed from other popular ontologies or specialized domain ontologies.

The Marl ontology is aligned with the W3C PROV Ontology (PROV-O) [12] to support provenance modeling. Provenance is information about the entities, activities, and people involved in producing a piece of data or thing, which can be used to form an assessment of its quality, reliability, and trustworthiness. The main concepts of PROV-O are entities, activities, and agents. Entities are physical or digital assets, such as web pages, spell checkers or, in our case, dictionaries or analysis services. Provenance records describe the provenance of entities, and an entity’s provenance can refer to other entities. For example, a dictionary is an entity whose provenance refers to other entities such as lexical entries. Activities are how entities come into existence. For example, starting from a webpage, a sentiment analysis activity creates an opinion entity describing the opinions extracted from that webpage. Finally, agents are responsible for the activities and can be a person, a piece of software, an organization, or other entities. The Marl ontology has been aligned with the PROV-O so that provenance of language resources can be tracked and shared.

The Marl ontology consists of four main classes as shown in Fig. 4.2: SentimentAnalysis, Opinion, AggregatedOpinion, and Polarity. They are related as follows: a SentimentAnalysis instance is an Activity that analyzes a source text to detect the Polarity of the Opinion expressed in that text. The main features of the extracted opinion are the polarity (hasPolarity), the polarity value (polarityValue) or strength, whose range is defined between minimum (minPolarityValue) and maximum (maxPolarityValue) values, and the described entity (describesObject) and feature (describesFeature) of that opinion. When several opinions are equivalent, we can opt to aggregate them into an AggregatedOpinion, which, in addition to the properties we have already mentioned, provides the number of users that the aggregated opinion represents (opinionCount). The polarity of opinions is represented by the Polarity base class. The Marl ontology comes with three instances of Polarity: Positive, Negative, and Neutral. Table 4.1 contains a comprehensive list of the properties associated with each of these classes.

3 Onyx: A Vocabulary for Emotion Annotation

The notion of emotion in psychological models is a subject of debate in current research. Scherer [13, 14] classifies the existing approaches for describing emotions into three categories: dimensional models, categorical models, and appraisal theories.

Dimensional models use one or more dimensions for distinct emotional states. The most widely accepted dimensions are arousal (or activation), valence (or pleasure), and dominance (or control). The dimension valence represents the pleasantness-unpleasantness dimension, and allows one to distinguish between positive and negative emotions. The dimension arousal refers to the intensity of the emotional activation, ranging from excited to calm. The dimension dominance represents the controlling and dominant nature of the emotion, ranging from dominant to submissive. Unidimensional models use the arousal or valence dimension. Multidimensional models use more than one dimension to characterize emotional states. There are several popular multidimensional models: two-dimensional models (valence, arousal) by Plutchick and Russell and three-dimensional models, such as the valence, arousal, and dominance model.

Categorical models, also known as discrete emotion models, suggest that there exists an innate set of basic emotions. The best known model is Ekman’s “big six”: anger, disgust, fear, happiness, sadness, and surprise.

Appraisal theories assume that emotions are elicited by a cognitive evaluation (appraisal) of situations and events that cause specific reactions in people, allowing for a large number of highly differentiated emotions. The result of the appraisal will generally have an impact on motivation, which changes the tendency for action.

Onyx [15] is a vocabulary that models emotions and the emotion analysis process itself. It can be used to represent the results of an emotion analysis service or the lexical resources involved (eg, corpora and lexicons). This vocabulary can be used to connect results from different providers and applications, even when different models of emotions are used.

At its core, the ontology has three main classes as shown in Fig. 4.3: EmotionAnalysis, EmotionSet, and Emotion. In a standard emotion analysis these three classes are related as follows: an EmotionAnalysis is run on a source (generally text, eg, a status update), and the result is represented as one or more EmotionSet instances that each contain one or more Emotion instances. The model of emotions in Onyx is very generic to reflect the lack of consensus on modeling and categorizing emotions. An advantage of this approach is that the representation and psychological emotion models are decoupled. Emotions have been described in a number of different ways, by means of categories (eg, “happiness”).

The EmotionAnalysis instance contains information about the source (eg, dataset) from which the information was taken, the algorithm used to process it, and the emotion model followed (eg, Plutchik’s categories). Additionally, it can make use of provenance to specify the agent in charge of the analysis, the resources used (eg, dictionaries), and other useful information.

An EmotionSet contains a group of emotions found in the text or one of its parts. As such, it contains information about the original text (extractedFrom), the exact excerpt that contains the emotion or emotions (emotionText), the person who showed the emotions (sioc:has_creator), the entity that the emotion is related to (describesObject), the concrete part of that object it refers to (describesObjectPart), the feature about that part or object that triggers the emotion (describesFeature), and the domain detected. All these properties are straightforward, but a comment about the domain property is necessary. Different emotions could have different interpretations in different contexts (eg, fear is positive when referred to a thriller but negative when it comes to cars and safety). When several EmotionSet instances are related, an AggregatedEmotionSet can be created that links to all of them. AggregatedEmotionSet is a subclass of EmotionSet that contains additional information about the original EmotionSet instances it aggregates. For instance, we could aggregate all the emotions related to a particular movie, or all the emotions shown by a particular user, and still be able to trace back to the original individual emotions.

Onyx’s Emotion model includes EmotionCategory, which is a specific category of emotion (eg, “sadness,” although more than one could be specified), linked through the hasEmotionCategory property; the emotion intensity via hasEmotionIntensity; action tendencies related to this emotion, or actions that are triggered by the emotion; appraisals and dimensions. Lastly, specific appraisals, dimensions, and action tendencies can be defined by extending Appraisal, Dimension, and ActionTendency, whose value should be a float number.

On top of that generic model we have included two different models: the WordNet-Affect taxonomy, and the Emotion Markup Language (EmotionML) vocabularies for categories, dimensions, and appraisals, which are detailed in Section 3.1.

Although emotional models and categories differ in how they classify or quantify emotions, they describe different aspects of the same complex emotion phenomenon [16]. Hence there are equivalence relationships between different categories or emotions in different models. To state such equivalence between emotion categories in Onyx one can use the properties defined in SKOS [17] such as skos:exactMatch or skos:closeMatch. This approach falls short when one is dealing with dimensional emotional theories or complex category theories.

Within a single model it is also possible that two separate emotions, when found simultaneously, imply a third one. For instance, “thinking of the awful things I’ve done makes me want to cry” might reveal sadness and disgust, which together might be interpreted as remorse. Some representations would refer to remorse as a complex emotion. Onyx purposely does not include the notion of complex emotions. It follows the same approach as EmotionML in this respect, as the Human-Machine Interaction Network on Emotion Annotation and Representation Language [18] included this distinction between simple and complex emotions but it was not included in the EmotionML specification. This simplifies the ontology and avoids discussion about the definition of complex emotions, since there are several possible definitions of a complex emotion, and different levels of emotions (eg, the hourglass of emotions model). One possible way to deal with such a situation is to add an AggregatedEmotion that represents remorse to the EmotionSet, linking it to the primary emotions with the aggregatesEmotion property.

Table 4.2 contains a comprehensive list of the properties associated with each of these classes. To group all the attributes that correspond to a specific emotion model, we created the EmotionModel class. Each EmotionModel will be linked to the different categories it contains (hasEmotionCategory), the Appraisal or Dimension instances it introduces (through hasAppraisal and hasDimension), etc. Having a formal representation of the categories and dimensions proves very useful when one is dealing with heterogeneous datasets in emotion analysis. In addition to being necessary to interpret the results, this information can be used to filter out results and for automation.

3.2 Emotion Markup Language

EmotionML does not include any emotion vocabulary in itself. However, the Multimodal Interaction Working Group released a series of vocabularies that cover the most frequently used models of emotions [19]. Users have to define their own vocabularies or reuse one of the existing ones. We have developed a tool that generates an EmotionModel model from a vocabulary definition, including all its dimension, category, appraisal, or action tendency entries. Using this tool, we have processed the vocabularies released by the Multimodal Interaction Working Group. EmotionML has four types of vocabularies, according to the type of characteristic of the emotion phenomenon they represent: emotion categories, emotion dimensions, appraisals, and action tendencies. If an emotion model addresses several of these characteristics, there will be an independent vocabulary for each of them. In Onyx, instead of following this approach, we opted for adding all characteristics in the same model. This results in cleaner uniform resource identifiers (URIs) and helps represent the emotion model as a whole (Listing 1).

4 Linked Data Corpus Creation for Sentiment Analysis

Some of the most valuable linguistic resources for sentiment analysis are labeled corpora for subjectivity, sentiment, and emotion analysis. Labeled corpora are used in a number of sentiment analysis tasks, such as polarity detection or sentiment lexicon generation. Nevertheless, there is not yet a widely accepted format for annotating sentiment corpora as illustrated in the following samples of a sentiment corpus (Listings 2 and 3) and an emotion corpus (Listing 4). Some additional problems we face are the different range of polarities in different datasets, as well as the use of different emotion models depending on the application field.

In this chapter we present how a sentiment corpus and an emotion corpus can be annotated through the use of NIF together with Marl and Onyx respectively. NIF 2.0 [26] is an RDF/OWL-based format that aims to achieve interoperability between natural language processing tools, language resources, and annotations. NIF provides a way to identify strings using URIs and annotate them with an ontology [27]. Strings are identified by URIs following a URI scheme based on RFC5147 [28], which standardizes fragment ids for texts. For a given document we want to annotate with NIF, the URI scheme consists of the URI of the document itself, a separator (#), and the character at the beginning and end of the string we want to annotate. Character indices in NIF are counted offset based, starting at zero before the first character and with the gaps between the characters counted until after the last character of the referenced string. After URIs have been assigned to meaningful strings of the corpus, these URIs can be annotated with the NIF core ontology, which provides classes and properties to describe the relationships between substrings, text, documents, and their URI schemes. NIF can be extended with vocabularies, such as Marl or Onyx, for specific purposes.

4.1 Sentiment Corpus

In this section we illustrate how a sentiment corpus can be annotated with Marl and NIF. We will annotate a review corpus following the sentiment tasks identified in the aspect-based sentiment analysis task of the challenge at SemEval 2004 [23], which was originally annotated as shown in Listing 3. The first step for annotating a corpus is to publish the corpus in a public URI. On the basis of NIF, offset-based URIs are assigned to every meaningful string of the corpus. Let us start by annotating the review “I love their fajitas, their pico de gallo is not bad, and the service is correct” as given in Listing 5. First, we annotate that the review has an opinion (opinion/1) in the offset (0,80), which in this case matches the full review. Then we annotate that this opinion is positive as is the provenance of the sentiment analysis task (analysis/1). Finally, we annotate and link two meaningful terms with entities of the DBpedia knowledge base. Since NIF follows an offset-based URI fragment scheme, single-word terms (eg, fajitas) as well as multiword terms (eg, pico de gallo) can be annotated. Since these two aspect terms have an associated polarity, we annotate that the opinion opinion/1 is an AggregatedOpinion that includes two opinions (opinion/2 and opinion/3) about the two aspect terms previously annotated.

Aspect-based sentiment analysis identifies the aspects of a given target entity and the sentiment expressed toward each aspect. Aspect categories (eg, food, price) identify coarser features than aspect terms, and they do not necessarily occur as terms in a given sentence. In our example, the terms fajitas and pico de gallo refer to the same aspect category food, while the term service refers to the aspect category service. In Listing 6 we annotate aspect categories and introduce the use of the property marl:describesFeature for this purpose.

4.2 Emotion Corpus

An emotion corpus can be annotated in the same way as a sentiment corpus but with use of the Onyx vocabulary instead of the Marl vocabulary. There are two main differences for annotating an emotion corpus. First, a sentiment analysis provides a certain polarity for a given string, while an emotion analysis can identify several emotions with different intensities. Second, the same corpus can be annotated on the basis of different emotion models. In Listing 4.7 we illustrate how the previous example can be annotated as a result of an emotion analysis.

5 Linked Data Lexicon Creation for Sentiment Analysis

Sentiment lexicons are lists of words with an associated a priori polarity or emotion. Some of the most popular sentiment lexicons are the NRC Emotion Lexicon [29], the MPQA Subjectivity lexicon [30], SentiWordNet [31], the Sentiment140 NRC Twitter Sentiment Lexicon [32], and Affective Norms for English Words (ANEW) [33], which are shown in Listing 8.

As shown, the available lexicons follow different formats, have different properties, and their values are not normalized. In addition to the interoperability problem, a major shortcoming of the available representations is that the polarity is assigned to a term, independently of its context. For example, the adjective cold will have a certain polarity (eg, positive) for cold beer but also for cold pizza. In this section we illustrate how the lemon lexicon model can be used together with Marl and Onyx to publish and interlink sentiment and emotion lexicons. Lemon builds on previous work on standards for the representation of lexical resources—that is, the Lexical Markup Framework [34]—but extends the underlying formal model and provides a native integration of lexicons with domain ontologies. The lemon model is described in detail in the lemon cookbook [35] and supports the linking of a computational lexical resource with the semantic information defined in an ontology. Lemon defines a set of basic aspects of lexical entries, including morphosyntactic variants and normalizations. Lexical entries can be linked to semantic information through lexical sense objects. In addition, lemon has a number of modules that allow further modeling. Currently defined modules are linguistic description, phrase structure, morphology, syntax and mapping, and variation.

5.1 Sentiment Lexicon

Sentiment lexicons can be expressed with lemon, which has been extended with two properties of Marl, marl:polarityValue and marl:hasPolarity. Polarities can be defined within a particular context of the lexical entry. For example, for the Spanish word susto (meaning “fright”), we can assign a positive polarity in horror movies but a negative polarity in children’s movies, as illustrated in Listing 4.9.

5.2 Emotion Lexicon

Lexical entries expressed with lemon can also be annotated with Onyx. Suitable emotion models should be selected depending on the application domain. An annotated example of the Affective Norms for English Words lexicon is shown in Listing 4,10, with use of the emotion model emoml:pad.

6 Sentiment and Emotion Analysis Services

NIF defines an input and output format for Representational State Transfer web services in the NIF 2.0 public application programming interface specification [36]. In this way, natural language processing tools and services can interoperate seamlessly. This specification defines a set of parameters that should be supported by NIF-compliant services, which have been extended for sentiment and emotion services as shown in Table 4.3.

The open source project Senpy [37] provides a reference implementation for sentiment and emotion services that is extendable through plugins. A number of wrappers have been developed for popular services such as Sentiment140 [38] test service interoperability. In addition, in the context of the European projects EuroSentiment and MixedEmotions, this application programming interface has been implemented by several vendors.

The example in Listing 11 shows how a sentiment service is invoked and how the output of that service is annotated with use of NIF together with Marl and Onyx.

7 Case Study: Generation of a Domain-Specific Sentiment Lexicon

This section presents a practical case study [39] of the use of the previously introduced technologies for the generation of a domain-specific sentiment lexicon from legacy language resources and enrichment with semantics and additional linguistic information from resources such as DBpedia and BabelNet. The language resources adaptation pipeline consists of four main steps highlighted by dark boxes in Fig. 4.4: (1) the corpus conversion step normalizes the different language resources to a common schema based on Marl and NIF; (2) the semantic analysis step extracts the domain-specific entity classes and named entities and identifies links between these entities and concepts from the LLOD cloud; (3) the sentiment analysis step extracts contextual sentiments and identifies SentiWordNet synsets corresponding to these contextual sentiment words; and (4) the lexicon generator step uses the results of the previous steps, enhances them with multilingual and morphosyntactic information, and converts the results into a lexicon based on the lemon and Marl formats. Different language resources are processed with variations of the given adaptation pipeline. For example, the domain-specific English review corpora are processed with the pipeline described in Fig. 4.4, while the sentiment annotated dictionaries are converted to the lemon/Marl format in the lexicon generator step.

Once the sentiment corpora have been converted and the domain-specific sentiment lexicon has been generated, we can use SPARQL to explore it as shown in Listing 12.

8 Conclusions

This chapter has provided an introduction to the potential and advantages of the use of a linked data approach for sentiment linguistic resources to overcome the interoperability problem and take advantage of the distributed annotation nature of the linked data cloud. The chapter has introduced the main concepts and technologies to annotate sentiment and emotion corpora, lexicons, and services, and how we can link lexical and semantic resources.

The technologies presented in this chapter have been evaluated in a number of research projects. The research projects TrendMiner [40] and FinancialTwitterTracker [41] have used Marl to annotate the opinion detected in financial news and the social network Twitter. Both projects allow users to visualize time-based sentiment and activity on a particular topic of interest and to compare them visually with the time series of a financial instrument. The research project MixedEmotions [42] is applying both Marl and Onyx for annotation of sentiment and emotion in three business cases: (1) annotation of phone calls in a call center for quality assurance; (2) annotation of emotion and sentiment in news and social networks for a brand monitoring system; and (3) annotation of emotion and sentiment social networks for a social TV system.

All that said, much remains to be done. On the one hand, linked data technologies are still not widely used by the computational linguistic and natural language processing communities. On the other hand, there is an increasing number of available datasets in the LLOD, and an ongoing community effort that supports this approach, such as the W3C Community Group on Linked Data Models for Sentiment and Emotion Analysis, the W3C Best Practices on Multilingual Linked Open Data Community Group, the W3C Ontology-Lexica Community Group, the W3C Linked Data for Language Technology Community Group, and the Open Linguistics Working Group of the Open Knowledge Foundation.

Despite these concerns, the increasing popularity of linked data technology and the availability of tools and resources are tremendous incentives for its adoption. Regarding the sentiment analysis community, the W3C Community Group on Linked Data Models for Sentiment and Emotion Analysis provides a suitable forum for fostering the adoption of linked data practices and the generation of interoperable sentiment language resources and services.

This chapter has presented the current directions in the publication of language resources for sentiment analysis as linked data. One of the future directions is the harmonization of metadata of existing language resources, as proposed by the Linghub project [43], which collects and harmonizes metadata from some of the existing language resources and publishes the records as linked data. In addition, one important aspect is the development of business models for sentiment language resources. One of the initial initiatives in this respect is the Eurosentiment project [44], which proposed a multilingual resource pool supported by a subscription business model. Moreover, given the scarcity of sentiment language resources for many languages, it is necessary to investigate automatic machine translation of these resources [45] and avoid the negative effect of low quality in these translations [46]. Finally, since the content shared in social networks is not only textual, multimodal sentiment analysis [47] aims at alleviating the ambiguity of text with the fusion of sentiment analysis of textual, visual, and audio modalities. This requires research on semantic models for annotating sentiment and emotion in multimodal resources [42].