Grupo de Sistemas Ingeligentes EWE Ontology

EWE Ontology Specification

V1.0 - 20 May 2013

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

Creative Commons License


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.


Table of Contents

  1. Introduction
    1. Task Automation Services
    2. The Semantic Web
    3. What is EWE for?
  2. EWE ontology at a glance
  3. EWE ontology overview
    1. Referrenced Namespaces
    2. EWE Channel example
    3. SPARQL Construct EWE Rule example
    4. Extended channel search example
  4. Cross-reference for EWE Classes and Properties

Appendixes

  1. Changelog
  2. Acknowledgements

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:

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
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
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.dit.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.dit.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 configuration?
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

[#] [back to top]


Class: foaf:Agent

Agent - It describes an Agent using the FOAF ontology
Status: unknown
Sub class of owl:Thing

[#] [back to top]


Class: ewe:Channel

Channel - It defines individuals that either generate Events, provide Actions or both. In the context we refer, Channel mostly defines Web Services. However, sensors and actuators are also described as channels, thus they produce events or provide actions (e.g. a GPS device programmed to generate alerts when it is near certain locations).
Status: unknown
Properties include: providesAction generatesEvent
Used with: hasActiveChannel uses supportsChannel
Sub class of owl:Thing

[#] [back to top]


Class: ewe:Event

Event - Event class defines a particular ocurrence of a process, they are generated by a particular Service (e.g. new_chat_message events are generated by GoogleTalk service). Events have no duration. Changes on the state of a system or a sensor, can be modeled as events (the change in the state triggers the Event generation).
Status: unknown
Used with: generatesEvent triggeredBy
Sub class of owl:Thing

[#] [back to top]


Class: ewe:InputParameter

InputParameter - InputParameters are configuration parameters that can be used to define the specific behavior of Events or Actions. Event's triggering conditions are set using InputParameters. Action's execution results is set using InputParameters.
Status: unknown
Used with: hasInputParameter
Sub class of Parameter

[#] [back to top]


Class: foaf:OnlineAccount

OnlineAccount - It describes an OnlineAccount using FOAF ontology. The OnlineAccount class represents the provision of some form of online service, by some party (indicated indirectly via a accountServiceHomepage) to some Agent. The account property of the agent is used to indicate accounts that are associated with the agent.
Status: unknown
Sub class of owl:Thing
Has sub class User

[#] [back to top]


Class: ewe:OutputParameter

OutputParameter - OutputParameters are more common in Events than in Actions. They specify the output arguments from an Event ocurrences. For instance, the timestamp of a chatmessage, the author of a tweet, the subject of an email, etc. The value of an output parameter is often bound to the input parameter while connected in a Rule.
Status: unknown
Used with: hasOutputParameter
Sub class of Parameter

[#] [back to top]


Class: ewe:Parameter

Parameter - Parameters provide additional data that is either consumed or generated by Actions or Services. Depending on the nature of the Paremeter they can be either InputParameter or OutputParameter. The value of a Parameter is given by the property dcterms:value, and its name by the property dcterms:title. The property dcterms:description can also provide an overview of its meaning and usage.
Status: unknown
Properties include: value
Used with: hasParameter
Sub class of owl:Thing
Has sub class InputParameter OutputParameter

[#] [back to top]


Class: ewe:Rule

Rule - Rule defines an ECA rule, triggered by an Event that means the execution of an Action. It defines particular interconections among instances of event and action, that includes the configuration parameters set for both of them. Rules are defined as a SPARQL construct query by means of the property spin:rule, using the SPIN language.
Status: unknown
Properties include: hasCreator timesUsed triggeredBy uses
Sub class of owl:Thing

[#] [back to top]


Class: tags:Tag

Tag - It describes a certain tag annotation using the tags ontology
Status: unknown
Used with: taggedWithTag
Sub class of owl:Thing

[#] [back to top]


Class: tags:Tagging

Tagging - It describes a set of tags applied to a certain resource by a certaing agent. Class from Tagging ontology.
Status: unknown
Used with: tag

[#] [back to top]


Class: ewe:TaskAutomationService

TaskAutomationService - This describes a Task Automation Service for the Evented Rules defined in EWE.
Status: unknown
Properties include: supportsChannel

[#] [back to top]


Class: ewe:User

User - It defines a User who define some AppRules among the services he has account in.
Status: unknown
Properties include: hasActiveChannel
Used with: hasCreator
Sub class of OnlineAccount foaf:OnlineAccount

[#] [back to top]


Properties

Property: dcterms:created

created - It indicates the data at wich a Rule was created.
Status: unknown
Domain: owl:Thing or ewe:Rule

[#] [back to top]


Property: ewe:generatesEvent

generatesEvent - Describes the event that can be generated by the Service (e.g. Weather forecast service may generate rain alert events).
Status: unknown
Domain: Channel
Range: Event
Has inverse property isGeneratedBy

[#] [back to top]


Property: ewe:hasActiveChannel

hasActiveService - It states that the User has the target service activated. This means, it has an acoount on that service and so he can use it.
Status: unknown
Domain: User
Range: Channel

[#] [back to top]


Property: ewe:hasCreator

hasCreator - The creator of the Rule. It enables user profiling and authoring.
Status: unknown
Domain: Rule
Range: User

[#] [back to top]


Property: ewe:hasInputParameter

hasInputParameter - Links Actions or Events to an Input-Parameter.
Status: unknown
Domain: ewe:Action or ewe:Event
Range: InputParameter
Sub property of hasParameter

[#] [back to top]


Property: ewe:hasOutputParameter

hasOutputParameter - Links Actions or Events to an Output-Parameter.
Status: unknown
Domain: ewe:Action or ewe:Event
Range: OutputParameter
Sub property of hasParameter

[#] [back to top]


Property: ewe:hasParameter

hasParameter - Links Actions or Events to a Parameter.
Status: unknown
Domain: owl:Thing or ewe:Action or ewe:Event
Range: Parameter
Has sub property hasOutputParameter hasInputParameter

[#] [back to top]


Property: ewe:isGeneratedBy

isGeneratedBy - It points out the Service that may generate the Event (e.g new chat message may be generated by Google Talk Service)
Status: unknown
Inverse property of the anonymous defined property with the label 'generatesEvent' (Object Property)

[#] [back to top]


Property: ewe:isProvidedBy

isProvidedBy - It points out a Service that provides the Action (e.g. send new blog entry is provided by a RSS channel)
Status: unknown
Inverse property of the anonymous defined property with the label 'provicesAction' (Object Property)

[#] [back to top]


Property: ewe:isUsedIn

isUsedIn - Describes an AppRule that is using any of the Events that generates or Actions that provides the Service
Status: unknown
Inverse property of the anonymous defined property with the label 'uses' (Object Property)

[#] [back to top]


Property: foaf:page

page - Describes the original web resource that the class models or referes to. It is described using the FOAF ontology, accordint to which, this points out to a document it is about.
Status: unknown
Domain: owl:Thing or ewe:Rule or ewe:TaskAutomationService or ewe:Channel

[#] [back to top]


Property: ewe:providesAction

provicesAction - Describe an action provided by the service (e.g. Email services provides send new email action)
Status: unknown
Domain: Channel
Range: Action
Has inverse property isProvidedBy

[#] [back to top]


Property: ewe:supportedBy

supportedBy - It indicates that a channel is supported by the TaskAutomationService given. It is said that a Channel is supported by a certain TaskAutomationService when rules that involve use of Events or Actions generated or provided by that Channel can be executed on the TaskAutomationService. It is used to build the list of TaskAutomationServices that support a certain channel.
Status: unknown
Inverse property of the anonymous defined property with the label 'supportsChannel' (Object Property)

[#] [back to top]


Property: ewe:supportsChannel

supportsChannel - It indicates that a TaskAutomationService supports the Channel given. It is said that a TaskAutomationService supports a certain Channel when rules that involve use of Events or Actions generated or provided by that Channel can be executed on the TaskAutomationService. It is used to define the list of Channels that a instance of TaskAutomationService supports.
Status: unknown
Domain: TaskAutomationService
Range: Channel
Has inverse property supportedBy

[#] [back to top]


Property: tags:tag

tag - It associates a resource to a Tagging object.
Status: unknown
Range: Tagging tags:Tagging

[#] [back to top]


Property: tags:taggedWithTag

taggedWithTag - It indicates that the object has been tagged with the Tag Object.
Status: unknown
Range: Tag tags:Tag

[#] [back to top]


Property: ewe:timesUsed

timesUsed - Statistical property that stores the number of times a Service, Event or Action has been used. Thus, the value it stores corresponds to an snapshot of the Rule Database, for instance, at the time of the extraction from the origian Task Automation Service.
Status: unknown
Domain: Rule
Range: xsd:int

[#] [back to top]


Property: ewe:triggeredBy

triggeredBy - Connects the left part of the ECA rule, the Event that triggers the rule.
Status: unknown
Domain: Rule
Range: Event

[#] [back to top]


Property: ewe:uses

uses - Points out a Service that is used in the definition of the AppRule, either in the left part -the event- or the right part -the action.
Status: unknown
Domain: Rule
Range: Channel
Has inverse property isUsedIn

[#] [back to top]


A. Change Log

2013 - 05 - 20

B. Acknowledgments

This documentation has been generated automatically from the most recent ontology specification in OWL using a python script called SpecGen. The style formatting has been inspired on FOAF specification.

Special thanks for support with ontology creation and research to: Prof. Carlos A. Iglesias and members of the GSI Group of DIT department of Universidad Politécnica de Madrid.

This work has been funded by the Spanish Ministerio de Economía y Competitividad through the Calista project (TEC2012-32457).