EWE Ontology Specification

V1.0 - 12 May 2017

This version:	http://gsi.upm.es/ontologies/ewe/1.0 (RDF/XML, HTML)
Latest version:	http://gsi.upm.es/ontologies/ewe
Editors:	Miguel Coronado, Sergio Muñoz, Carlos A. Iglesias
Authors:	Miguel Coronado
Contributors:	See acknowledgements

This work is licensed under a Creative Commons Attribution License. This copyright applies to the EWE Ontology Specification and accompanying documentation in RDF. This ontology uses W3C's RDF technology, an open Web standard that can be freely used by anyone.

Abstract

Evented WEb Ontology (EWE) is a standardized data schema (also referred as "ontology" or "vocabulary") designed to describe elements within Task Automation Services enabling rule interoperability. The following document contains the description of ontology and instructions how to connect it with descriptions of other resources.

Introduction
EWE ontology at a glance
EWE ontology overview
Cross-reference for EWE Classes and Properties

1 Introduction

The following specification is a formal description of metadata schema proposal that can be applied to data gathered in the so-called Task Automation Services. The goal of the following section is to introduce both Semantic Web and Task Automation Services to the topic and goals of the ontology and provide the basic knowledge to comprehend the technical part of the specification.

1.1 Task Automation Services

A number of now prominent web sites, mobile and desktop applications feature rule-based task automation. Typically, these services provide users the ability to define which action should be executed when some event is triggered. Some examples of this simple task automation could be “When I am mentioned in Twitter, send me an email”, “When I reach 500 meters of this place, check in in Foursquare”, or “Turn Bluetooth on when I leave work”. We call them Task Automation Service (TAS). Some TASs allow users to share the rules they have developed, so that other users can reuse these tools and adapt them to their own preferences.

Task Automation is a rising area, recently lots different web services and mobile-apps focus their business on this topic. Although the concept is not new, several changes on the state of technology supports the success of these services and applications. Among them the massive publishing of third-party APIs on the Cloud, providing access to their services is a key factor that unchained this mushrooming.

We could find several details that difference these services to each other. Some are web services and some are mobile-apps, so they distinguish their scope. Those smartphone based focus on those capabilities that are provided by the device that cannot be addressed in a web environment: switching on/of BT under certain conditions, automatically connect the wireless receiver when we reach some place, automation based on positioning, based on the level of the battery etc. At the time of writing these lines, there is no Task Automation Service that cover both a web service and a smartphone application, i.e. that let you define rules that mix both worlds, triggered by events from the web that execute tasks on the mobile phone, or vice versa.

We can also classify them according to the target audience. Some of them focus on the user, on automation of their repetitive task, e.g. changing Twitter's profile picture when we change Facebook's, or texting my mother that I'm running out of battery when its level is below 10%. For of the mobile based TAS are of this type. Some other, are more specific and focus on business tasks. We can perceive this by examining the category of the services (so-called channels) they integrate. Also, depending on the process used to create the rule, we can infer the target, this is, those that provide a rule language are focused on programmers.

Some of the most popular Task Automation Services are:

1.2 The Semantic Web

The Semantic Web is a W3C initiative that aims to introduce rich metadata to the current Web and provide machine readable and processable data as a supplement to human-readable Web.

Semantic Web is a mature domain that has been in research phase for many years and with the increasing amount of commercial interest and emerging products is starting to gain appreciation and popularity as one of the rising trends for the future Internet.

One of the corner stores of the Semantic Web is research on inerlinkable and interoperable data schemas for information published online. Those schemas are often referred to as ontologies or vocabularies. In order to facilitate the concept of ontologies that lead to a truly interoperable Web of Data, W3C has proposed a series of technologies such as RDF and OWL. EWE uses those technologies and the research that comes within to propose an ontology set in the domain of Task Automation Services.

1.3 What is EWE for?

The goals of the EWE ontology to achieve are:

Enable to publish raw data from Task Automation Services (Rules and Channels) online and in compliance with current and future Internet trends
Enable Rule interoperability
Provide a base vocabulary for building domain specific vocabularies e.g. Twitter Task Ontology or Evernote Task Ontology

2. EWE ontology at a glance

An alphabetical index of EWE terms, by class (concepts) and by property (relationships, attributes), are given below. All the terms are hyperlinked to their detailed description for quick reference.

3. EWE ontology overview

The EWE UML diagram presented below shows connections between classes that implement the data model of Task Automation Services.

UML Class Diagram for the EWE Ontology (high resolution version: PNG)

3.1. Referenced Namespaces

A common practice in Semantic Web domain is to take advantage of the work previously done and model new domains with the use of widely known and well established vocabularies. This practice simplifies the vocabulary pool, allows to establish naming standards and implement better interoperability and data portability across potentially very different systems.

We attempted to follow those rules, thus some of the classes and properties defined in this specification have references to properties from other ontologies to indicate point of connection. Those referenced ontologies are described with the following namespaces:

Prefix	Namespace	Specification/ Usage Description
dcterms	http://purl.org/dc/terms/	Dublin Core Terms ontology is a core ontology that defines a number of very generic properties such as title, description, value, etc. Those are used across many classes in the EWE ontology.
foaf	http://xmlns.com/foaf/0.1/	Friend Of A Friend ontology. Within EWE it is used to model concepts related to user account and the digital personification of a human being.
skos	http://www.w3.org/2004/02/skos/core#	Simple Knowledge Organization System is a common data model for knowledge organization systems such as thesauri, classification schemes, subject heading systems and taxonomies. Within EWE, it is used to describe different categories of Channels and Events.
tags	http://www.holygoat.co.uk/owl/redwood/0.1/tags/	Newman's Tags ontology. The concepts of this ontology are used as a base model tags.
spin	http://spinrdf.org/spin#	SPARQL Inferencing Notation. EWE's rules are described using SPIN SPARQL Syntax, an RDF representation of the semantic web query language SPARQL.

The next diagram summarizes relation between external vocabularies and their relation to EWE.

Diagram that shows relation among external vocabularies and EWE (PNG).

3.2. EWE Channel example

A very basic example below shows a single Channel described using EWE vocabulary. It defines a new subclass of Channel that outlines how GoogleTalk Service works. As defined below, Gmail Channel generates two events and provide one single action. These are "Any new email" and "New email from" events and "Send an email" action (their RDF description is not shown in the example below for sake of simplicity).

This is a real example of class definition scrapped from ifttt.com (channel definition provided here). Note that the current version of channel description at ifttt.com may differ from the description shown here, due to ifttt is in continuous expansion, remodeling their channels, so new events or actions may have been added since this example was written down .

    <owl:Class rdf:about="https://ifttt.com/gmail">
      <rdfs:subClassOf rdf:resource="http://gsi.upm.es/ontologies/ewe/ns#Channel"/>
      
      <!-- Administrative properties -->
      <dcterms:title>Gmail</dcterms:title>
      <dcterms:description>
        Gmail is a free, advertising-supported webmail, POP3, and IMAP service provided by Google.
      </dcterms:description>
      <foaf:logo>https://ifttt.com/images/channels/gmail_lrg.png</foaf:logo>
      
      <!-- Categorization -->
      <ewe:hasCategory rdfs:resource="http://gsi.upm.es/ontologies/ewe/ns#email">
      
      <!-- Functionalities -->
      <ewe:generatesEvent rdf:resource="https://ifttt.com/channels/gmail/triggers/85"/>
      <ewe:generatesEvent rdf:resource="https://ifttt.com/channels/gmail/triggers/86"/>
      <ewe:hasAction rdf:resource="https://ifttt.com/channels/gmail/actions/34"/>
    </owl:Class>

In the former example events and actions are included as external references. This is the preferred way for describing channels, since it is easier to read, and offers a more modular view of the model. However, as in any other RDF graph, RDF entities can be nested, thus we can include the Event or Action definition nested within the Channel definition. We could even add them as black entities or nodes if there is no need to reference them from the outside (this is without relating them to the Channel that defines them), although not common and it is discouraged.

The example below provides the description of the "New Email from" Event referenced at the Gmail Channel definition from the example above. The event shown presents one input parameter -the email address of the sender- and three output parameters -the email address of the sender, the subject of the email, and the body of the message in plain text.

In this case, parameters are included as nested elements instead of being referenced as external resources. Although parameters have not been given an ID (for sake of simplicity on the example) we encourage you to do so. Moreover, the reference-to-external-resources is also an acceptable approach (once more, we did not use it here to save the reader from following multiple link from the referral to the definition).

  <owl:Class rdf:about="https://ifttt.com/channels/gmail/triggers/86">
    <rdf:type rdf:resource="http://www.semanticweb.org/ontologies/2012/9/ewe.owl#Event"/>
    <dcterms:title>New email from</dcterms:title>
    <dcterms:description>
      This Trigger fires every time a new email arrives in your inbox from the address you specify.
    </dcterms:description>

    <!-- Input Parameters -->    
    <ewe:hasInputParameter>
      <ewe:InputParameter>
        <dcterms:title>EmailAddress</dcterms:title>
      </ewe:InputParameter>
    </ewe:hasInputParameter>
    
    <!-- Output Parameters -->
    <ewe:hasOutputParameter>
      <ewe:OutputParameter>
        <dcterms:title>FromAddress</dcterms:title>
        <dcterms:description>Email address of sender.</dcterms:description>
      </ewe:OutputParameter>
    </ewe:hasOutputParameter>
    <ewe:hasOutputParameter>
      <ewe:OutputParameter>
        <dcterms:title>Subject</dcterms:title>
        <dcterms:description>Email subject line.</dcterms:description>
      </ewe:OutputParameter>
    </ewe:hasOutputParameter>
    <ewe:hasOutputParameter>
      <ewe:OutputParameter>
        <dcterms:title>BodyPlain</dcterms:title>
        <dcterms:description>Plain text email body.</dcterms:description>
      </ewe:OutputParameter>
    </ewe:hasOutputParameter>
    
  </owl:Class>

Just one more detail, the former example uses the properties ewe:hasInputParameter and ewe:hasOutputParameter to reference the Input and Output Parameters. However, the parent hasParameter could have also been used with OutputParameter or InputParameter. When the inference engine is available, both approaches are equivalent and any query that matches one of them will also match the other. Nevertheless, when it is not, the procedure shown is more explicit, thus preferred.

3.3. SPARQL Construct EWE Rule example

The example below shows how is a EWE rule defined using a CONSTRUCT query.

The rule in the example sends the user a new chat message thought the GoogleTalk channel every time a new email is received. The content of the chat message specify the senders email address, so the user can decide if it is important or not.

In detail, the WHERE graph selects all events whose title is "Any new mail", that also have an output

  CONSTRUCT {
      ?action a ewe:Action .
      ?action dcterms:title "New chat message" .
      ?action ewe:hasParameter ?iParam .
      ?iParam dcterms:title "message" .
      ?iParam dcterms:value ?message .
      <https://ifttt.com#GoogleTalk;> ewe:providesAction ?action .
  }
  WHERE {
      ?event a ewe:Event .
      ?event dcterms:title "Any new email" .
      ?event ewe:hasOutputParameter ?oParam .
      <https://ifttt.com/Gmail> ewe:generatesEvent ?event .
      ?oParam dcterms:title "FromAddress" .
      ?oParam dcterms:value ?oParamFrom .
      BIND (fn:concat("You have received a new message from ", ?oParamFrom) AS ?message) .
      BIND (URI("http://example.org/action1") AS ?action) .
      BIND (URI("http://example.org/param1") AS ?iParam) .
  }

The former rule is written using a SPARQL CONSTRUCT query. It can be transformed into a RDF format using the SPIN language. This provide some advantages such as the capability of store the rule in the RDF endpoint with the Channels, Events and Actions. It is executable code, since SPIN libraries provide functions to transform it back to the defining SPARQL query and also to execute it directly. In addition, since the rule is loaded in the endpoint, it can be queried to get rules that meet a certain criteria.

The example below shows an SPARQL query to extract all the EWE rules stored that connects Gmail's events to Google talk's actions.

  SELECT * WHERE {
      _:srule rdf:type ewe:SpinRule ;
              dcterms:title ?ruletitle ;
              spin:rule _:aux1 .
      _:aux1 sp:where _:aux2 .
      _:aux2 rdf:rest*/rdf:first ?triplet_w .
      ?triplet_w sp:predicate ewe:generatesEvent ; 
                 <sp:subject https://ifttt.com/gmail> .
      _:aux1 sp:templates _:aux3 .
      _:aux3 rdf:rest*/rdf:first ?triplet_t .
      ?triplet_t sp:predicate ewe:providesAction ; 
                 sp:subject <https://ifttt.com/gtalk> .

  }

3.4. Enhance channel search example

Modeling Task Automation Service assets using EWE Ontology provides a great deal of expressiveness, enhancing search queries of Channels and Rules. The example below shows several meaningful queries that can be done:

Query	SPARQL Query	Results
How many channels are defined by each Task Automation Service?	SELECT ?tas (COUNT(?channel) AS ?channels) WHERE { ?channel rdfs:subClassOf ewe:Channel . ?channel ewe:supportedBy ?tas } GROUP BY ?tas	Zapier (141), Tasker (22), Ifttt (59)
Which channel categories are defined?	SELECT DISTINCT ?category WHERE { ?channel rdfs:subClassOf ewe:Channel . ?channel ewe:hasCategory ?category }	Event Management, CRM, Phone, Developer Tools, Email Marketing, Social and 9 more.
Which channels are categorized as social?	SELECT ?channelName WHERE { ?channel rdfs:subClassOf ewe:Channel . ?channel ewe:hasCategory ewe:Social . ?channel dcterms:title ?channelName }	Wordpress, chatter, buffer, facebook, twitter, and 7 more
Which channels are categorized as ’developer tools’ and ’Phone’?	SELECT ?channelName WHERE { ?channel rdfs:subClassOf ewe:Channel . ?channel ewe:hasCategory ewe:Phone . ?channel ewe:hasCategory ewe:Developer_Tools . ?channel dcterms:title ?channelName }	Twillio and Opsgenie
Which channels’ events can be used without conﬁguration?	SELECT DISTINCT ?channelName ?eventName WHERE { ?channel rdfs:subClassOf ewe:Channel . ?channel dcterms:title ?channelName . ?channel ewe:generatesEvent ?event . ?event dcterms:title ?eventName . FILTER NOT EXISTS { ?event ewe:hasInputParameter ?inp } } GROUP BY ?channelName ?eventName	Paypal’s Succecc Sale, Olark’s New Message, Google-doc’s New Document and 324 more.
How many actions can be executed by means of the Tasker TAS?	SELECT (COUNT(?action) AS ?actsProvided) WHERE { ?channel ewe:hasAction ?action . ?channel ewe:supportedBy ewe:Tasker } GROUP BY ?channel	204 actions

4. Cross-reference for EWE classes and properties

Below see a comprehensive list of all EWE classes, properties and their descriptions.

Classes and Properties (full detail)

Classes

Class: ewe:Action

Action - Action class defines an operation or proccess provided by a Service. Actions produce effects whose nature depend on the action's nature (e.g. producing a log message, modifying a public or private state on a server, switching on a ligth, etc.). Actions are on the right part of the Rule. Web services, actuators, and smartphone apps can provede actions when modeled as Services

Status:	unknown
Used with:	providesAction
Sub class of	owl:Thing

Status:	unknown
Properties include:	providesAction generatesEvent
Used with:	hasActiveChannel uses supportsChannel
Sub class of	owl:Thing

Status:	unknown
Domain:	Channel
Range:	Event
Has inverse property	isGeneratedBy

Status:	unknown
Inverse property of	the anonymous defined property with the label 'generatesEvent' (Object Property)

EWE Ontology Specification

V1.0 - 12 May 2017

Abstract

Table of Contents

Appendixes

1 Introduction

1.1 Task Automation Services

1.2 The Semantic Web

1.3 What is EWE for?

2. EWE ontology at a glance

3. EWE ontology overview

3.1. Referenced Namespaces

3.2. EWE Channel example

3.3. SPARQL Construct EWE Rule example

3.4. Enhance channel search example

4. Cross-reference for EWE classes and properties

Classes and Properties (full detail)

Classes

Class: ewe:Action

Class: foaf:Agent

Class: ewe:Channel

Class: ewe:Event

Class: ewe:InputParameter

Class: foaf:OnlineAccount

Class: ewe:OutputParameter

Class: ewe:Parameter

Class: ewe:Rule

Class: tags:Tag

Class: tags:Tagging

Class: ewe:TaskAutomationService

Class: ewe:User

Properties

Property: dcterms:created

Property: ewe:generatesEvent

Property: ewe:hasActiveChannel

Property: ewe:hasCreator

Property: ewe:hasInputParameter

Property: ewe:hasOutputParameter

Property: ewe:hasParameter

Property: ewe:isGeneratedBy

Property: ewe:isProvidedBy

Property: ewe:isUsedIn

Property: foaf:logo

Property: foaf:page

Property: ewe:providesAction

Property: ewe:supportedBy

Property: ewe:supportsChannel

Property: tags:tag

Property: tags:taggedWithTag

Property: ewe:timesUsed

Property: ewe:triggeredBy

Property: ewe:uses

A. Change Log

2017 - 05 - 12

2013 - 05 - 20

B. Acknowledgments