Knowledge Engineering in a Temporal Semantic Web Context

Viorel Milea, Flavius Frasincar, and Uzay KaymakFaculty of Economics, Erasmus University RotterdamP.O. Box 1738, 3000 DR Rotterdam, The Netherlands

{milea, frasincar, kaymak}@few.eur.nl

Abstract

The emergence of Web 2.0 and the Semantic Web asestablished technologies is fostering a whole new breedof Web applications and systems. These are often cen-tered around knowledge engineering and context aware-ness. However, adequate temporal formalisms underlyingcontext awareness are currently scarce. Our focus in thispaper is two-fold. We first introduce a new OWL-based tem-poral formalism - TOWL - for the representation of time,change, and state transitions. Based hereon we present a fi-nancial Web-based application centered around the aggre-gation of stock recommendations and financial data.

1. Introduction

Information on the Web is mostly textual in nature. Itscharacter is descriptive and meaningless without its mostskilled interpreter: the human brain. If the goal of automat-ing the aggregation of vast amounts of information is tobe achieved, then this information should be described in amachine-readable way enabling applications to at least sim-ulate some understanding of the data being processed. Theemergence of Web 2.0 [12] and the Semantic Web [2] asestablished technologies is fuelling a transition from a webof data to a web of knowledge. In turn, this knowledge richenvironment is fostering a whole new breed of Web applica-tions and systems, centered around knowledge aggregationand context awareness. Focussing on the latter, it can right-fully be stated that enabling context awareness involves theexistence of adequate temporal formalisms - currently veryscarce in a Semantic Web context. This results in adhoc(and often not reusable) solutions for dealing with temporalaspects on the Web.

One of the domains with a prominent temporal aspect,which forms the focus of our current research, is the fi-nancial one. More specifically, we seek to explore the areaof engineering Web applications for automated trading, anarea far too little investigated in such a context. One of the

motivations behind this choice finds its origins in the factthat, in 2006, automated trading accounted for no less thana third of all share trades in America. By 2010, accordingto consultancy firm Aite Group, it will make up more thanhalf the share volumes and a fifth of options trades [3].

The main drive of this increased demand for automatedsupport in financial markets can be accounted to differentfactors. One of the most obvious reasons underlying thistrend is the tight correlation between the timing of a tradeand the generated return. A number of aspects play a partherein, such as the time required for the aggregation of therelevant information on the human side; this period intro-duces an unavoidable lower bound on the time of the traderelative to the moment when it becomes profitable based onthe available signals. Another factor that fuels the involve-ment of automated systems on the decision-side of finan-cial markets consists of the discovery of arbitrage oppor-tunities. The increased efficiency of mature financial mar-kets, as well as the large number of assets and derivativesavailable, make the identification of market inefficiencieshighly challenging. Automating at least parts of this pro-cess should result in an increased coverage of the market,as well as in an increased quantitative expectation from thistype of speculative returns. Finally, we underline the hu-man aspect as one of the main drives behind the migrationfrom trader-driven investments to computer(-aided) trades.We refer here mostly to error proneness, especially in con-ditions of stress or extreme situations.

Although seemingly not directly related to automatedtrading, the Semantic Web may come to meet the increasedtechnological demands emerging in the world of trading[10, 15]. In achieving this purpose, we deem it necessaryto provide extensions to current Semantic Web languages,thus making the latter more suitable for the knowledge weseek to represent. One such extension is presented in thispaper and concerns a temporal ontology language based onOWL-DL - the TOWL language. This language stands atthe basis of the financial application we present in this pa-per, and forms one of the key ingredients allowing the ag-gregation of historical stock recommendations and financial

Eighth International Conference on Web Engineering

978-0-7695-3261-5/08 $25.00 © 2008 IEEE

DOI 10.1109/ICWE.2008.10

65

data.This paper is organized as follows. In Section 2 we

present an overview of known approaches towards tempo-ral representations on the Semantic Web. In Section 3 weintroduce our temporal extension of OWL-DL: the TOWLlanguage. Section 4 presents the TOWL-based financial ap-plication developed in the context of the current researchboth in terms of its key features as well as the results gen-erated. We wrap up in Section 5 with some conclusions re-garding the main ideas presented in this paper and possiblefuture work.

2. Related Work

The focus of this section is on previous approaches re-garding temporal Semantic Web extensions. The first ap-proach we present, in Section 2.1 regards the extension ofRDF with temporal labeling of triples. In Section 2.2 wegive an overview of an OWL ontology of time, while inSection 2.3 we report a previous effort of integrating a per-durantist approach towards change in OWL, again in theform of an ontology.

2.1. Temporal RDF

A rather extensive approach towards extending ontol-ogy languages with a temporal dimension is reported in [4].This work is similar to our current goal as it concerns theability to represent temporal information in ontologies, butdiffers in that the language considered is the Resource De-scription Framework (RDF). The concrete result of this ap-proach consists of temporal RDF graphs with underlyingtemporal semantics allowing for temporal entailment.

The extension presented in [4] with regard to RDF con-sists of a vocabulary extension focused on temporal la-beling. This vocabulary extension enables the labeling oftriples with intervals, thus allowing for the representationof the time period during which the triple is true. Buildingfurther upon this idea, the authors introduce the concepts ofgraph slices and graph snapshots. Given a time t, graphslices can be seen as subgraphs consisting of all triples withtemporal label t, while graph snapshots consist of all triplesholding true at t.

This labeling approach is suitable for the representationof both transaction and valid time, as known from temporaldatabases. Additionally, it preserves the spirit of the dis-tributed and extensible nature of RDF, while keeping ob-ject proliferation limited in scenarios where changes arefrequent [4]. The time used is a discrete and linearly or-dered domain, again presenting resemblance with temporaldatabases.

However, the approach presented in [4] is mainly fo-cused on representing different versions of RDF graphs, as

they hold at different moments in time. In other words,temporal RDF is centered around representing and track-ing change. For our current purpose, although relevant, wedeem this to be insufficient, as we seek represent state tran-sitions next to the ephemeral traits of entities.

2.2. OWL-Time

The initial purpose behind the design of a time ontologywas to represent the temporal content of Web Pages andthe temporal properties of Web Services (DAML-Time) [5].The latest version of this ontology is represented in OWL,and is currently a W3C working draft, as of September 27th,2006.

The time ontology is built around the TemporalEntityclass and the relations describing its individuals. Temporalentities may be of two types: Instant (point-like momentsin time) and Interval (time descriptions having a duration,represented as ordered pairs of Instant individuals). Ad-ditionally, the ontology contains classes meant to describedifferent other temporal concepts, such as duration (Dura-tionDescription), dates and times (DateTimeDescription),temporal units (TemporalUnit) and alternative representa-tions for the days of the week (DayOfWeek).

The main relations describing individuals of type Instantare the functional properties begins (the beginning, same asthe end in case of an instant) and ends (the end, same as thebeginning in case of an instant). The range of the propertiesare objects of type InstantThing. The actual time belong-ing to these individuals can be expressed as of the inter-nal type CalendarClockDescription or as xsd:dateTime ofXML Schema. Intervals exhibit, amongst others, the sameproperties as instants, with the same flexibility in the rep-resentation of the actual date and/or time. Additionally, theproperty inside may be defined in the case of individuals oftype Interval, and describing a relation between an Instantand an Interval, equivalent to asserting that some individualof type Instant is within the bounds of the individual of typeInterval.

In the context of designing a temporal language, the ex-pressiveness offered by OWL-Time addresses mainly theissue of the representation of time in its qualitative nature.However, the main building block of this approach is OWL-DL, resulting in a limited representational power even atthis level. A very simple example relates to the seman-tics of an interval - the left bound of the interval shouldalways be smaller than the right bound of that same interval- which cannot be represented in OWL-DL. Despite this,the approach also exhibits a number of interesting features,such as the reference to XML Schema for the representa-tion of dates and times, and the use of intervals as the mainbuilding block for more complex constructions.

66

2.3. An OWL Ontology for Fluents

Perdurantism, or four-dimensionalism, relates to theview of entities as having more than only their spatial parts:they also have a temporal part. For the current purposewe focus on perdurantism and the corresponding view onthe temporal parts of an object: “... something persists iff,somehow or other, it exists at various times; something per-dures iff it persists by having different temporal parts, orstages, at different times, though no part of it is whollypresent at more than one time” [6].

An approach related to incorporating perdurants throughthe use of timeslices and fluents in OWL-DL is presented in[14], where the authors develop a reusable ontology for flu-ents in OWL-DL. The fundamental building blocks of thisrepresentation are timeslices and fluents. Timeslices repre-sent the temporal parts of a specific entity at clear momentsin time and the concept itself is then defined as all of itstimeslices. Fluents are nothing more than properties thathold at a specific moment in time, may this time be an in-stant (point-like representation of time) or an interval. Theontology for fluents as defined in [14] is reproduced in Fig-ure 1.

Ontology(4dFluentsClass(TimeSlice)DisjointClasses(TimeSlice TimeInterval)Property(fluentProperty Symmetricdomain(TimeSlice)range(TimeSlice))

Property(tsTimeSliceOf Functionaldomain(TimeSlice)range(complementOf(TimeInterval))

Property(tsTimeInterval Functionaldomain(TimeSlice)range(TimeInterval)))

Figure 1. The original fluents ontology as pre-sented in [14].

The approach in [14] comes to address a relevant issue,namely the representation of change in OWL ontologies.However, as in the case of OWL-Time, relying solely onOWL-DL for such a goal limits in several ways the power ofthe approach. The semantic limitation regarding temporalaspect translates to little to no reasoning support in suchcontexts.

3. The TOWL Language

In this section we formally introduce the TOWL lan-guage [11]. The concepts discussed are introduced both inabstract as well as description logics (DL) syntax. A furtherdifferentiation is made between syntax and semantics of theconcrete domain and the syntax and semantics of fluents

Figure 2. The TOWL layer cake.

and timeslices. Finally, we differentiate between TBox andABox syntax and semantics, and present these separately.

An overview of the layers introduced by TOWL as anextension to OWL-DL is given in Figure 2. In what followswe present the different layers in more detail, introducingthe syntax and semantics belonging to each. It should benoted that some of the layers do not necessarily introducea semantic extension, as in the case of timeslices and flu-ents where it can be argued that this layer concerns syntacticsugaring.

3.1. Concrete Domains

The first step towards increasing the expressiveness ofOWL-DL in a temporal fashion consists of extending thecapabilities of the language regarding concrete domains.OWL-DL does offer a certain level of support for concretedomains. It is thus possible to represent concrete traits ofentities based on quantifiable attribute values and datatypeproperties. The datatype properties can be created at the de-sign stage and linked to XML Schema Datatypes. In thisfashion, simple concepts such as age, height, and even tem-poral durations may be represented.

However, for the current purpose, we deem this to beinsufficient. Truly meaningful representations in a tempo-ral context relate, for a a large part, to complex temporalrestrictions enabled by the language. Such constructionsare usually built using function compositions, equivalentto functional role chains in OWL-DL. Complex class def-initions involving a temporal aspect are represented basedon such chains, with the important characteristic that thisdefinition involves the concrete domain. Translating this toOWL-DL involves the representation of restrictions throughconcrete domain predicates imposing some restriction offunctional role chains. This type of representations are notonly relevant in a temporal context. Even in a static envi-ronment one can envision some concrete relation restrictinga class definition based on concrete feature chains. The gen-eral form of a functional role chain in DL is:

f1 ◦ f2 ◦ ... ◦ fn ◦ g

67

In TOWL we make this type of constructs available bymeans of syntactic sugaring. The representation of a con-crete feature chain in TOWL abstract syntax is as follows:

ConcreteFeatureChain(f1 f2 ... fn g)

where f1,...,fn are abstract features and g is a concretefeature pointing to some value in the concrete domain.

In what follows, we denote by ui concrete feature chainsof the form introduced above. Developing hereon, we ad-ditionally introduce restrictions imposed through the use ofconcrete domain predicates over such chains. The generalform of such restrictions in DL is:

∃u1, u2.pd,

where pd is a concrete domain predicate and u1, u2 areconcrete feature chains. In TOWL, such restrictions are rep-resented as:

dataSomeValuesFrom (u1 u2 pd),

where u1, u2, pd preserve their meaning as previouslypresented. Additionally, we can also represent universalquantification over such restrictions, what in DL would berepresented as:

∀u1, u2.pd,

which translates, in TOWL abstract syntax, to:

dataAllValuesFrom (u1 u2 pd),

For example, if we base our approach on a concrete do-main describing dates and times (which in turn is based onthe set Q of rational numbers with < and = as its two bi-nary predicates), we can express restrictions of the follow-ing form in DL syntax:

∃u1, u2. <∀u1, u2. =

which are completely equivalent to the following repre-sentations in TOWL abstract syntax:

dataSomeValuesFrom (u1 u2 numeric-smaller-than)dataAllValuesFrom (u1 u2 numeric-equal)

To summarize, the concrete domains layer in TOWLbuilds upon the expressiveness offered by concrete domainsadded to OWL-DL. This increased expressiveness comesfrom allowing complex class definitions where a concretedomain predicate that is used to restrict paths in the form ofconcrete feature chains.

A special type of concrete domain is represented by con-straint systems [7]. The main discriminating characteristic

of such systems is the type of predicates they are based on.Unlike traditional concrete domains, constraint systems arebased on a set of jointly-exhaustive and pairwise disjointbinary relations. This makes constraint systems suitable fortemporal representations based on intervals and Allen’s in-terval relations [1], as we discuss in the next section. Ad-ditionally, such an extensions maintains the decidability ofthe language, as shown in [7].

3.2. Time Representation

The concrete domain in the TOWL context, as presentedin the previous section, enables the representation of timein the language. Under this TOWL layer we include basicrepresentations of time in the form of temporal intervals, aswell as a number of temporal relations between these inter-vals in the form of Allen’s 13 interval relations. This formsthe basis for our approach, as it allows the definition of com-plex restrictions, such as the one described in the previoussection, but this time having a temporal character. The typeof concrete domain considered is a constraint system basedon intervals and Allen’s relations that may hold between in-tervals [8].

By employing this particular concrete domain, we canexpress Allen’s 13 [1] interval relations in the languageand enable the representation of temporal dependencies be-tween events. It should be noted that all relations betweenintervals can be translated to formulas in terms of the inter-vals’ endpoints.

3.3. Timeslices & Fluents

The concrete domain approach towards representingquantitative time in ontologies as presented in the previoussections forms the basis for our approach. Building furtherupon these blocks, we seek to represent temporal aspects ofentities other than timespan. In this context, the final levelof expressiveness that we enable in TOWL regards changeand state transitions. The perdurantist approach outlinedin Section 2.3 forms the foundation of this type of features.The current approach builds upon the concrete domain layerfor the representation of time as described in this document.Up to a certain level, it can be argued that the fluents andtimeslices employed for the representation of temporal in-formation do not go beyond the expressiveness of OWL-DL. Rather, fluents and timeslices represent a kind of vo-cabulary employed for the representation of temporal partsof individuals that change some property in time. However,the semantics of fluents as envisioned for TOWL enforcesa number of restrictions on TOWL specific concepts, andmost importantly on fluents and timeslices. Some inter-esting features fuel the interdependence between the con-crete domain and the timeslices/fluents approach and relate

68

Figure 3. Temporal restrictions on timeslicesconnected by fluents.

mostly to the restrictions this approach imposes on the veryconcepts it introduces. A concrete example of this interde-pendence consists of employing the definition of the intervalas introduced in the previous sections in defining the timeassociated with timeslices (the period over which timesliceshold true).

One such restriction relates to the fact that fluents onlyrelate timeslices that hold over the same time interval. Rep-resenting such a restriction involves the concept of equal-ity of (feature chains ending with) intervals, a representa-tion that is enabled through the use of the constraint systembased on intervals and Allen’s relations. We illustrate thisidea through an example that we graphically depict in Fig-ure 3.

For illustrating this point, we represent a buy advice is-sued by the company Credit Suisse for Philips. We assumethe existence of a Company class in the ontology. Two in-stances of this class are created, iCreditSuisse and iPhilips,denoting the two companies involved. For each of thesestatic individuals we create a timeslice, resulting in iCred-itSuisse TS1 and iPhilips TS1, respectively. The times-lices are associated to the concept they describe throughthe towl:timeSliceOf property. The towl:time property isemployed to associate a time interval to each of the times-lices, in this case iIntervalCS and iIntervalPh, respectively.Both intervals are described in terms of their starting andending points through the towl:start and towl:end proper-ties. Finally, we connect the two timeslices through theadvice:buyAdvice fluent, thus representing the buy adviceissued by Credit Suisse for Philips.

Returning to the point of restrictions enabled by theTOWL language - fluents may only connect timeslices thathold over the same interval - through the use of the con-

straint system we enforce the towl:equal Allen relation tohold between the intervals that describe the two timeslices.In the context of TOWL, the Allen relations are defined asbinary predicates over the concrete domain, and are em-ployed to specify such restrictions as follows (in DL no-tation):

∃(time, fluentObjectProperty ◦ time).equal

Enforcing such an axiom may have two consequences:

• If the intervals do not satisfy the equal relation, an in-consistency is discovered;

• If one of the intervals is not defined, its endpoints maybe inferred from the other interval.

However, as argued later in this section, the second pointdoes not apply, as we enforce timeslices to always be as-sociated with a timeinterval for which both endpoints aredefined.

At this point, is should be mentioned that, building uponthe approach in [14], TOWL enables differentiations be-tween fluents that take values from the TimeSlice class andfluents that indicate changing values (datatypes). This isachieved through the use of the FluentObjectProperty andFluentDatatypeProperty properties, and comes to reducethe proliferation of objects in TOWL ontologies due to thefact that, in the case of datatypes, the number of timeslicesthat need to be created is reduced to half.

A final issue that needs to be addressed relates to theFrame Problem. In the current case, this resumes to be-ing able to determine, at any point in time, what holds trueand what not. What we are trying to cope with also relatesto being able to determine what has not been affected byan action. In Figure 4 we present two concepts, Concept1and Concept2, each with timeslices across different time in-tervals. If timepoint T is chosen, it becomes obvious thatdetermining what holds true at that time is a simple mat-ter. This is however only possible if we enforce timeslicesto always be associated with a time interval that indicatesthe period across which these timeslices hold true. The def-inition of a TOWL timeslice, as formalized in the TOWLsemantics, satisfies this condition.

4. Stock Recommendations Aggregation Sys-tem

Stock recommendations, although taking on different de-nominations, can always be reduced to advices of the formbuy/hold/sell. They are issued by large brokerage firms,and mirror the expectations regarding the development ofthe stock price of the envisioned company. The collectionof such recommendations that are true at a given point in

69

Figure 4. Determining what holds true at acertain point in time.

time is denoted as market consensus, and can often be agood indicator of the average expectation regarding the fu-ture (within 1 year) value of a company. Roughly, a stockrecommendation thus consists of the issuer (the brokeragefirm), the targeted company and the type of the advice(buy/hold/sell). Although other characteristics may be in-cluded in such a recommendation, such as 12-months pricetarget, 12-months earnings per share, etc., they fall out ofscope for the current purpose.

Going beyond pure market consensus, an interesting re-search question is whether these recommendations can beaggregated into a single advice such that the aggregated ad-vice is a better indicator of how the price of a certain stockis likely to develop. The most intuitive variable to considerin this context is the historical performance of the individ-ual brokerage firms present in the market consensus. Thisis exactly the goal of the Stock Recommendations Aggre-gation System (SRAS). This section focuses on outliningthe system and, additionally, presenting preliminary resultsobtained through the aggregation of advices.

4.1. System Architecture

In this section we provide an overview of SRAS in termsof the system’s architecture. The individual components aredescribed in more detail in the following sections. A graph-ical depiction of SRAS is presented in Figure 5. Here, thedifferent modules are grouped according to the system com-ponent they belong to.

A distinction may be made between the following com-ponents:

• HTML wrappers;

• Information extraction;

• Knowledge base update;

• Advice generation.

A walkthrough the system, at a general level, involvesfetching data from the HTML data sources, extracting the

Figure 5. System architecture.

relevant knowledge and updating the TOWL knowledgebase. Based hereon, the SRAS advice generation compo-nent aggregates the available information and presents a sin-gle advice to the end-user (i.e., trader).

4.2. HTML Wrappers

One of the main features of the system consists of thevarious raw data sources employed for the generation of ad-vices. Additionally, different types of data are employed forthe purpose of the system. In this section we describe boththe sources as well as the type of data we extract for thecurrent purpose.

The main data ingredient consists of the raw ad-vices, in the form of buy/hold/sell recommendations.Emerging advices are grabbed from the http://www.analist.nl, http://www.iex.nl and http://www.briefing.com websites, which are updated on adaily basis. We focus on a total of 8 markets: EuronextAmsterdam, Euronext Brussels, Euronext Paris, DAX 30,DowJones 30, FTSE 100, NASDAQ 100 and SMI. His-

70

torical advices are fetched for the purpose of determiningthe past performance of brokerage companies. A compre-hensive resource for this type of data is the Wharton Re-search Data Center (WRDS), available at http://wrds.wharton.upenn.edu/.

Next to data that directly concerns stock recommenda-tions, we collect different characteristics of companies, suchas the company codes, and the markets and sectors in whichthey are active. Thomson One Banker (T1B) provides ex-tensive information for this purpose, together with historicaldaily closing stock price data for the companies consideredby SRAS. The set of company features that we considerconsists of attributes such as company name and quote sym-bol, but also a series of different codes that uniquely iden-tify companies: such as ISIN, SEDOL, CUSIPa and IBES.Additionally, we include the GICS code, the is used to iden-tify the industry classification to which a certain companybelongs.

The need for being able to identify companies by differ-ent codes (ISIN, SEDOL, etc.) emerges from the fact that,in different contexts, the company may be identified by anyof these codes (think of the data extracted from HTML ad-vices). Additionally, as all these codes are generally usedjust as often, we provide different means of identifying acompany at application level.

The data described in this section is grabbed from thedifferent data sources through the use of individual HTMLwrappers, and fed to the Information Extraction component,which we describe next.

4.3. Information Extraction

The first module of the Information Extraction com-ponent is the Stanford Part-of-Speech (POS) tagger [13].Some of the commonly used tags that we found in the de-scription of stock recommendations include: /NNP (propernoun, singular), /IN (preposition or subordinating conjunc-tion), /CD (cardinal number), /NN (noun, singular or mass),/DT (determiner), /JJ (adjective) and/VBZ (verb, 3rd personsingular present). The individual recommendations, as pro-vided by the HTML wrapper, are annotated word by wordbased on the part of speech they represent.

After having annotated the textual data by means of theStanford POS tagger, the tagged information is further pro-cessed. The relevant knowledge is extracted by means ofpattern-based extraction. In the case of stock recommen-dations, the goal of this phase is to identify the followingfeatures:

• Issuer: the brokerage firm that issued the recommen-dation;

• Company: the company for which the recommenda-tion was issued;

• Advice type: the type of the advice, one ofbuy/hold/sell;

• Identifier: unique code of the company for which theadvice was issued;

• Issue date: the date when the advice was issued.

Regarding the time associated with the validity of the ad-vice, a sidenote is in place. At the time an advice is issued,it is not known for how long this recommendation will holdtrue. In other words, the recommendation might expire withno special events occurring, or a new recommendation maybe issued. For this goals, at the time the advice is created bySRAS, a default validity period of 12 months is assumed. Inthe case that during this period a new advice is issued by thesame brokerage firm for the same company the length of theold advice is adjusted so that it ends right before the new onewas issued. This temporal feature of the system will furtherbe detailed when discussing the Knowledge Base Updatecomponent.

After having tagged and extracted the relevant knowl-edge from the raw input, this data is passed on to the Knowl-edge Base Update module. The main purpose of this mod-ule is the creation of TOWL instances that reflect the rel-evant knowledge extracted from the various data sources.In the case of recommendations, timeslices of the broker-age firm and the company are created with the correspond-ing time intervals. The timeslices are connected with theappropriate fluent (e.g., buyAdvice in the case of a buy ad-vice). The thus created data is passed on to the informationto the Knowledge Base Update component.

4.4. Knowledge Base Update

The knowledge base (KB) employed by SRAS is pop-ulated with static information once before the fetching ofadvices is initiated. All static information regarding compa-nies, codes and exchanges is present, although the processof populating the KB with this knowledge may be repeatedon user demand. The high quantity and very low rate ofchange of this data make it unfeasible to initiate this pro-cess each time new advices are grabbed.

The main task of the component discussed in this sec-tion thus consists of updating the KB with the newly issuedstock recommendations, as received from the InformationExtraction component. This task is achieved by employ-ing Jena [9] - a Semantic Web framework designed for themanipulation of ontologies. In combination with the rule-based inference engine provided by Jena, it becomes pos-sible to check for temporal constraints and inconsistencies,in addition to the static ones. This can be achieved throughcustomizing the Jena engine by an extension that includestemporal rules.

71

Figure 6 shows an example of a TOWL Jena rule, i.e., therule used to check if an instance is inside a certain interval.This rule uses the before predicate to verify whether thestarting point of an interval is before a given instance andwhether the instance is before the ending point of the in-terval. The before predicate is defined in another TOWLJena rule which uses the lessThan function (available inJena for comparing xsd:dateTime expressions).

# inside[inside:(?ins rdf:type time:InstantThing)(?int rdf:type time:IntervalThing)(?int time:start ?intstart)(?int time:end ?intend)(?ins time:before ?intend)(?intstart time:before ?ins)->(?ins time:inside ?int)]

Figure 6. TOWL Jena rule example.

An interesting feature at this stage is the adjustment ofthe length of the advices based on the current context. Asalready mentioned, the duration of advices is not known atthe time the advice is issued. However, TOWL enforces alltimeslices to be described by a defined interval, and thus anending point for the interval (i.e., the recommendation) isnecessary. The temporal rule we employ for this purpose isinitially based on adding a default duration of 12 months toeach newly issued advice. If, during the update of the KB,an advice is discovered that is identical to the advice thatis being added in terms of issuer and target company, theendpoint of the old advice is adjusted. We assume of coursethat the advice, though old, is not older than 12 months.The new ending date of the interval associated with the oldadvice is set to one day before the new advice was issued,and the new advice may now be added to the KB withoutaffecting the consistency of the old advice.

After each update of the KB, the system generates newaggregated advices for the company where changes are de-tected following the process described in this section. Morelight is shed on the generation of aggregated advices in thenext section.

4.5. Aggregated Advice Generation

The focus of this section is on the core module of theStock Recommendations Aggregation System, namely theAdvice Aggregator. The computation of the actual aggre-gated advices is based, as previously mentioned, on the in-dividual performance of the brokerage firms present in themarket consensus for which the system generates a recom-mendation, at the time this recommendation is calculated.We base this calculation on the Performance Index (PI) ofeach broker, in turn based on the profitability (generated re-

turn) of the broker. This is calculated based on the perfor-mance of the individual advices issued by the latter. How-ever, due to the varying duration of advices, absolute returnproves to be a subjective measure of performance. For thisreason, we rely on the average daily return.

We first introduce the daily return of an advice, calcu-lated according to the following formula:

Rdailyt =

pricet − pricet−1

pricet−1

Based on the daily return, the average return of an adviceis calculated according to the following formula, where n isthe total number of days across which the advice was true:

Radvice =∑n

t=1 Rdailyt

n

Finally, the performance index of a brokerage firm is cal-culated as the average return that all its advices generated:

PIbroker =∑m

advice=1 Radvice

m,

where m is the total number of advices issued by a singlebroker.

It should be noted that the range of advices consideredwhen calculating the performance index may vary, accord-ing to user preferences. One obvious option is selecting allrecommendations that the brokerage firm issued. Anotheroption however, is to narrow the set of considered advicesto those issued for companies active in the same industry asthe company for which an advice is generated by SRAS. Byrelying on the GICS code for this task, the field of advicesmay be varied based on the selected length of this code.

The next step in the generation of an advice is determin-ing the confidence factors for each type of possible recom-mendations (buy/hold/sell), based on the performance in-dexes. For each of type of recommendation, the confidencefactor CF [buy,hold,sell] is calculated as follows, provided atleast one performance index is positive:

∑pi=1 PI

[buy,hold,sell]i∑q

j=1 PIbuyj +

∑rk=1 PIhold

k +∑s

l=1 PIselll

where PI [buy,hold,sell] represents the performance indexof the broker that issued a [buy, hold, sell] advice, p rep-resents the total number of brokerage firms in the marketconsensus, and q, r, s the number of brokerage firms in themarket consensus that issue a buy, hold or sell advice, re-spectively, such that p = q + r + s.

72

Figure 7. The standard tab.

In case all advices are negative, the confidence factorsare calculated as follows:

1 −|∑p

i=1 PI[buy,hold,sell]i |

|∑q

j=1 PIbuyj +

∑rk=1 PIhold

k +∑s

l=1 PIselll |

This is done so that, despite the negative values, a properscaling may still be achieved. In this fashion, confidencefactors may be determined regardless of the nature (posi-tive/negative) of the performance indexes, while maintain-ing the ability to compare results.

Having calculated a confidence factor for each type ofrecommendation based on market consensus and historicalinformation, the type of advice issued by the application isthe one with the highest confidence factor after performingthe calculations presented in this section.

Additionally, we calculate a strength, Sadv , for the ad-vice issued by the application, based on the individual con-fidence factors. This is calculated as:

Sadv = (max(CF buy, CFhold, CF sell)-−min(CF buy, CFhold, CF sell) ++max(CF buy, CFhold, CF sell)-−median(CF buy, CFhold, CF sell))/2

The intuition behind this formula relates to regarding thestrength of advices in terms of whether there is a clear dis-crimination between the confidence factors of the differentadvice types. Additionally, this ‘distance’ is quantified, thusproviding the strength of the advice.

4.6. User Interface & Preliminary Results

The user interface is divided into 4 tabs, as presented inFigure 7, where the default tab - Standard - is selected.

In this tab the user can select a company by typinganything from the company name to one of the available

Figure 8. The advanced tab.

Figure 9. The GICS tab.

company identifiers (codes). Once selected, a period tobe considered when calculating the aggregated advice maybe selected. Finally, upon clicking the Gather New Ad-vice button, an aggregated advice is generated following themethodology as outlined in the previous section.

The second tab, Portfolio, is identical to the Standardtab, with the exception that here the user may select a wholerange of companies rather than just one, and receive advicesfor each selected company.

The Advanced tab allows the user to select what lengthof the GICS code of the selected company is going to beused when calculating the aggregated recommendation. Asshown in Figure 8, the GICS code of the selected companyis already shown, and can be edited by the user. Addition-ally, information on the GICS code is available, at differentlengths of this code.

Finally, the GICS tab presents the average performanceof brokerage firms within a specific GICS industry. Asshown in Figure 9, the GICS code is editable, and any length(maximum 8) may be entered when performing this bench-mark.

The preliminary results present a number of interestingfeatures. Perhaps the most striking one relates to the factthat the aggregated recommendation generated by SRAS

73

does not always follow the market consensus. In otherwords, a recommendations distribution (across buy, holdand sell) that has a unique maximum (say buy), does notalways agree with the advice generated by the application.This occurs especially when taking into account the perfor-mance of the brokerage firms within the specific industrywhere the company for which the advice is generated is ac-tive. This could be an indicator that taking into account his-torical performance of brokerage firms leads to the creationof new knowledge regarding the most likely development ofa company’s share price.

5. Conclusion and Future Work

The TOWL language is an extension of OWL-DL thatenables the representation of time and temporal aspectssuch as change. It comes to meet shortcomings of previousapproaches, such as [5, 14] that only address this issue to alimited extent and don’t seek to enable automated reasoningin a temporal context.

The approach presented in [5] for example only dealswith the representation of time in the form of intervals andinstants. However, ensuring that intervals are properly de-fined (starting point is always strictly smaller than the end-ing point) is not possible in this approach. The approachtaken in [14] builds upon [5] by addressing one of its limi-tations, namely: the representation of temporal aspects suchas change. However, the semantics underlying this ap-proach are still OWL-DL semantics, and thus no reasoningsupport is provided for representations based on timeslicesand fluents other than the standard (and insufficient) OWL-DL reasoning.

The TOWL language has been developed as an extensionof OWL-DL to address a need that initiated at a practical(application) level. Developing financial applications in aSemantic Web context requires an increased level of contextawareness and thus support for the representation of highlydynamic data. One such application is the Stock Recom-mendations Aggregation System that we present in this pa-per. Here, the temporal data consists of emerging advicesthat must be represented consistently in the knowledge base.Enabling the aggregation of recommendation data and otherfinancial information results in a powerful application ableto issue single advices, of different strengths. The prelimi-nary results show that the informational content of this ag-gregated knowledge is increased when compared to the in-dividual advices.

Acknowledgement

The authors are partially supported by the EU fundedIST STREP Project FP6 - 26896: Time-determined

ontology-based information system for realtime stock mar-ket analysis. More information is available on the officialwebsite1 of the project.

References

[1] J. Allen. Maintaining knowledge about temporal intervals.Communications of the ACM, 26(11):832–843, 1983.

[2] T. Berners-Lee, J. Hendler, and O. Lassila. The semanticweb. Scientific American, 284(5):28–37, 2001.

[3] Economist. Algorithmic trading: ahead of the tape. TheEconomist, (383):85, 2007.

[4] C. Gutierrez, C. Hurtado, and A. Vaisman. Introducing timeinto RDF. IEEE Transactions on Knowledge and Data En-gineering, 19(2):207–218, 2007.

[5] J. Hobbs and F. Pan. An ontology of time for the semanticweb. ACM Transactions on Asian Language InformationProcessing, 3(1):66–85, 2004.

[6] D. Lewis. Counterparts of Persons and Their Bodies. TheJournal of Philosophy, 68(7):203–211, 1971.

[7] C. Lutz and M. Milicic. A tableau algorithm for descriptionlogics with concrete domains and general tboxes. Journal ofAutomated Reasoning, 38(1–3):227–259, 2007.

[8] C. Lutz and M. Milicic. A tableau algorithm for descriptionlogics with concrete domains and general tboxes. Journal ofAutomated Reasoning, 38(1–3):227–259, 2007.

[9] B. McBride. Jena: Implementing the RDF model and syntaxspecification. In Proceedings of the Second InternationalWorkshop on the Semantic Web (SemWeb 2001), 2001.

[10] A. Micu, L. Mast, V. Milea, F. Frasincar, and U. Kay-mak. Financial news analysis using a semantic web ap-proach. Semantic Knowledge Management: an Ontology-based Framework. Idea Group, 2008. To appear.

[11] V. Milea, F. Frasincar, U. Kaymak, and T. di Noia. An OWL-based approach towards representing time in web informa-tion systems. In The 4th International Workshop of Web In-formation Systems Modeling Workshop (WISM 2007), pages791–802. Tapir Academic Press, 2007.

[12] T. O’Reilly. What is web 2.0: design patterns and businessmodels for the next generation of software. http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.

[13] K. Toutanova and C. Manning. Enriching the knowledgesources used in a maximum entropy part-of-speech tagger.In Proceedings of the Joint SIGDAT Conference on Em-pirical Methods in Natural Language Processing and VeryLarge Corpora (EMNLP/VLC 2000), pages 63–70, 2000.

[14] C. Welty and R. Fikes. A reusable ontology for fluentsin OWL. In Formal Ontology in Information Systems:Proceedings of the Fourth International Conference (FOIS2006), pages 226–336. IOS Press, 2006.

[15] H. Zhu, S. E. Madnick, and M. Siegel. Reasoning about tem-poral context using ontology and abductive constraint logicprogramming. In Principles and Practice of Semantic WebReasoning, Second International Workshop (PPSWR 2004),volume 3208 of Lecture Notes in Computer Science, pages90–101. Springer, 2004.

1http://www.towl.org

74