The 5th edition of the Workshop on Ontology and Semantic Web Patterns (WOP2014) was be the very first in Europe, in which traditionally the design pattern community for Semantic Web and Linked Data had been very strong. The aim of the workshop was twofold: (i) providing an arena for proposing and discussing good practices, patterns, pattern-based ontologies, systems etc., and (ii) broadening the pattern community that is developing its own language for discussing and describing relevant problems and their solutions.
WOP2014 was a full-day workshop, co-located with the 13th International Semantic Web Conference, that included an invited talk, paper presentations and posters. The invited talk was given by Valentina Presutti and was entitled ”Fueling the future with Semantic Web Patterns”. Altogether, WOP2014 received 10 research paper submissions and 2 pattern paper submissions. From among these submissions, the Program Committee selected 6 research papers and 2 pattern papers for the presentation at the workshop. The poster session included 4 posters (2 of them presented pattern papers, and the remaining 2 presented patterns that were described within research papers).
This year’s Workshop on Ontology and Semantic Web Patterns o↵ ered a fasttrack submission of selected papers to the Semantic Web journal’s special issue on ontology design patterns. Authors of best papers were invited to submit a revised and extended version of their work to the journal. Based on the reviewer scores, the Organization Committee decided to invite two papers. To ensure objectivity, this decision was verified with the members of the Steering Committee.
We thank the Program Committe and the Steering Commitee for their hard work, and the authors for submitting their papers and for addressing the reviewers comments. We thank our invited speaker, Valentina Presutti, for the interesting and inspiring talk. We also thank the organisers of the 13th International Semantic Web Conference for hosting WOP2014 at ISWC2014.
Further information about the Workshop on Ontology and Semantic Web Patterns can be found at: http://ontologydesignpatterns.org/wiki/WOP: 2014.
November 2014
Fueling the future with Semantic Web Patterns
Valentina Presutti1,2 Abstract. I will claim that Semantic Web Patterns can drive the next technological breakthrough: they can be key for providing intelligent applications with sophisticated ways of interpreting data. I will picture scenarios of a possible not so far future in order to support my claim. I will argue that current Semantic Web Patterns are not su cient for addressing the envisioned requirements, and I will suggest a research direction for fixing the problem, which includes the hybridization of existing computer science pattern-based approaches, and human computing. A pattern-based ontology for describing publishing workflows Aldo Gangemi1,2, Silvio Peroni1,3,
David Shotton4, and Fabio Vitali3 Abstract. In this paper we introduce the Publishing Workflow Ontology (PWO), i.e., an OWL 2 DL ontology for the description of generic workflows that is particularly suitable for formalising typical publishing processes such as the publication of articles in journals. We support the presentation with a discussion of all the ontology design patterns that have been reused for modelling the main characteristics of workflows. 1
Keeping track of publication processes is a crucial task for publishers. This activity allows them to produce statistics on their goods (e.g., books, authors, editors) and to understand whether and how their production changes over time. Organisers of particular events, such as academic conferences, have similar needs. Tracking the number of submissions in the current edition of a conference, the number of accepted papers, the review process, etc., are important statistics that can be used to improve the review process in future editions of the conference.
Some communities have started to publish data, e.g., the Semantic Web Dog Food5 and the Semantic Web Journal6, which describe those scholarly data as RDF statements in the Linked Data, in order to allow software agents and applications to check and reason on them, and to infer new information. However, the description of processes, for instance the peer-review process or the publishing process, is something that is not currently handled – although sources of related raw data exist (e.g., EasyChair metadata). Furthermore, having these types of data publicly available would increase the transparency of the aforementioned processes and allow their use for statistical analysis. Of course, a model
6 Semantic Web Journal: http://semantic-web-journal.com. for describing these data is needed. Moreover, the model should be easy to integrate and adapt according to the needs and constraints of di↵ erent domains (publishing, academic conferences, research funding, etc.).
In this paper we introduce the Publishing Workflow Ontology (PWO), that we developed in order to accommodate the aforementioned requirements. This ontology is one of the Semantic Publishing and Referencing (SPAR) Ontologies7 (which have been created for the description of di↵ erent aspects of the publishing domain), and allows one to describe the logical steps in a workflow, as for example the process of publication of a document. Each step may involve one or more events that take place at a particular phase of the workflow (e.g., authors are writing the article, the article is under review, a reviewer suggests to revise the article, the article is in printing, the article has been published, etc.). This ontology has been developed in order to allow its use with other SPAR Ontologies as well as other models and existing data.
The rest of the paper is organised as follows. In Section 2 we discuss some related works on workflows within the Semantic Web domain. In Section 3 we provide the definitions of workflow we have used as starting point for modelling our ontology, and discuss the use of some existing ontology design patterns for addressing the modelling issues related to the main characteristics of workflows. In Section 4 we introduce PWO, describing how it extends the aforementioned patterns in order to handle the main components of workflows, and we support the discussion by means of a real example of publication process of an article of the Semantic Web Journal. Finally, in Section 5 we conclude the paper sketching out some future works. 2
In the last years the Semantic Web community have started on working and
proposing models for the formalisation and description of generic workflows, and
have shown several applications of these models/theories within the publishing
domain. Maybe the first huge-impact project on these topic has been Workflow
4ever (STREP FP7-ICT-2007-6 270192)8 [
As already stated, one of the outcomes of the project has been the proposal
for workflow-centric Research Objects [
Another interesting proposal for describing workflows is the work done by
Garijo and Gil [
Finally, among the other proposals for describing workflows, it worths mentioning the OWL ontology proposed by Sebastian et al. [18] for describing generic workflows, which reuses existing ontologies such as the Change and Annotations Ontology (ChAO) [13], and the SCUFL2 Core ontology13 that has been used to describe workflows in Taverna14, an open source and domain-independent Workflow Management System [19]. 3
In order to design an ontology for modelling (publishing) workflows, we have to understand what are the minimal characteristics that such ontology should address and if we can reuse some existing modelling solutions. Oxford Dictionaries defines workflow as follows: “The sequence of industrial, administrative, or other processes through which a piece of work passes from initiation to completion.”15
From this definition it is possible to identify some important characteristics of any workflow, i.e., the fact that it involves a sequence of processes that allow to initiate and then complete a piece of work during a specifiable time interval. The definition of the SearchCIO website is still more specific: “Workflow is a term used to describe the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step in a business process.”16
From this definition we can spot other crucial aspects. First of all, its structural organisation in procedural steps, each of them describes tasks performed by organisations and people, and each step requires some input information and tools in order to produce an output. Using these two definition as input, we 11 Open Provenance Model for Workflows: http://www.opmw.org/ontology/. 12 Ontology for Provenance and Plans: http://purl.org/net/p-plan#. 13 http://ns.taverna.org.uk/2010/scufl2 14 http://www.taverna.org.uk 15 http://www.oxforddictionaries.com/definition/english/workflow 16 http://searchcio.techtarget.com/definition/workflow can identify some well-known ontological patterns that already address, from an abstract point of view, some of the aspects related of workflows.
Participation. The participation pattern17 is a simple pattern that allows us to describe processes, events, or states (through the class Event), and to specify the various objects (through the class Object) that participate in these events.
This pattern seems to be very useful to define workflows as events involving people, organisations, places, and other objects as participants, as well as to link workflows and related activities to the expected steps .
Sequence. The sequence pattern18 is another pattern that can be used between tasks, processes or time intervals, in order to define sequences of such objects through direct (i.e., directlyFollows and directlyPrecedes) and transitive relations (i.e., follows and precedes). It is, of course, very useful to describe the logical organisation of the various steps of a workflow.
Control flow and plan execution. The control flow pattern19 is an OWL
representation of some of the constructs defined in the Workflow Patterns20 by
Wil van der Alst (cf. [17]). Either action or control (e.g., branching, concurrency,
looping) tasks are represented and related by means of the sequence pattern.
Tasks are distinct from activities, which are supposed to be executed based on the
task structure. This link is made in the context of the basic plan description21 and
the basic plan execution22 patterns, which reuse the foundational descriptions
and situations pattern to relate task compositions (plans) to organised activities
(plan executions). A comprehensive presentation is provided in [
These patterns are of course, very useful to describe the kinds of steps (the term used here for tasks) in a workflow and in general in publishing workflows. The action and control tasks from the control flow pattern are not specialised in the publishing workflow pattern, because they are expected to work as they are (by typing the steps according to their workflow semantics) when the need for control flows emerges in a planned workflow.
Time-indexed situation. The time-indexed situation pattern23 allows the description of a situation (i.e., the class TimeIndexedSituation) – i.e., a view on a set of entities linked to it through the property isSettingFor – that is explicitly indexed at some time specifiable through the property atTime linking a time interval (i.e., an instance of the class TimeInterval).
This pattern can be used to describe steps from an abstract point of view as kinds of situations representing the settings for all the events and input/output material needed or produced by these steps. Notice that time-indexed situation combines perfectly with plan execution in order to provide a temporal ordering to activities organised into a plan. 17 http://www.ontologydesignpatterns.org/cp/owl/participation.owl 18 http://www.ontologydesignpatterns.org/cp/owl/sequence.owl 19 http://www.ontologydesignpatterns.org/cp/owl/controlflow.owl 20 The Workflow Patterns page is: http://www.workflowpatterns.com. 21 http://www.ontologydesignpatterns.org/cp/owl/basicplandescription.owl 22 http://www.ontologydesignpatterns.org/cp/owl/basicplanexecution.owl 23 http://www.ontologydesignpatterns.org/cp/owl/timeindexedsituation.owl
Error Ontology. The Error Ontology24 is a unit test that produces an
inconsistent model if a particular (and incorrect) situation happens. It works by
means of a data property, error:hasError, that denies its usage for any resource,
as shown as below (in Manchester Syntax [
Domain : error : hasError exactly 0
Range : xsd : string
A resource that has an error makes the ontology inconsistent, since its domain is “all those resources that do not have any error:hasError assertion”.
This model is very useful in our context in order to define constraints on the input/output objects needed by the steps of a workflow. For instance, we could use it to deny the use of a certain object as input of a step if it will be produced only as output of one of the following steps. 4
In order to accommodate workflow requirements, we developed the Publishing Workflow Ontology25 (PWO), which is entirely based on the ontology patterns introduced in Section 3. This ontology allows one to describe the logical steps in a workflow, as for example the process of publication of a document. Each step may involve one or more events (or actions) that take place to a particular phase of the workflow (e.g., authors are writing the article, the article is under review, a reviewer suggests to revise the article, the article is in printing, the article has been published, etc.).
As shown in Fig. 1, PWO is based on two main classes, which are: – class pwo:Workflow. It represents a sequence of connected tasks (i.e., steps) undertaken by the agents; it is a subclass of plan:PlanExecution26; – class pwo:Step. It is an atomic unit of a workflow, subclass of taskrole:Task; it is characterised by a (required) starting time and an ending time, and it is associated with one or more events (activities) that are executed within the step. A workflow step usually involves some input information, material or energy needed to complete the step, and some output information, material or energy produced by that step. In the case of a publishing workflow, a step typically results in the creation of a publication entity, usually by the modification of another pre-existing publication entity, e.g., the creation of an edited paper from a rough draft, or of an HTML representation from an XML document. 24 http://www.essepuntato.it/2009/10/error 25 http://purl.org/spar/pwo 26 Note that in PWO we are not using explicitly the separation between workflow definition and workflow execution, since PWO has been thought as an ontology to provide a retrospective description of running workflows. Even if this is a simplification of the whole approach described by the imported patterns, we decided to include both patterns for workflow definition and execution in order to handle even workflow definitions in case we may need it (even if we have not yet explored this use of PWO properly).
PWO was implemented according to the aforementioned ontology patterns. As shown in Table 1, such patterns have been used as follows: – plan execution to describe workflows as plans, and their executions; – time-indexed situation to describe workflow steps as entities that involve a duration and that are characterised by events and objects (needed for and produced by the step); – sequence to define the order in which steps appear within a workflow; – control flow to describe the specialization and nature of steps at planning time; – participation to describe events (and eventually agents involved) taking part in the activities carried out according to the steps.
In addition, by means of the Error Ontology, we can generate an inconsistency every time the steps of a workflow are not arranged in a correct temporal order. In particular, an error is raised when a step requires (property pwo:needs) to use a particular object that will be produced (property pwo:produces) as consequence of another sequent step. The following excerpt shows the implementation of this constraint through a SWRL rule [10]: Step (? step1 ) , Step (? step2 ) , needs (? step1 ,? resource ) , produces (? step2 ,? resource ) , sequence : precedes (? step1 ,? step2 ) -> error : hasError (? step1 ," A step cannot need a resource that will be produced by a following step "^^ xsd : string )
In the next subsections we show how to describe the process of publication
of a journal article step by step. In particular we introduce how PWO can be
used in combination with existing data of the Semantic Web Journal27 [11] and
other SPAR ontologies, such as PSO [15], C4O [
A typical publishing workflow of a journal article From a pure publisher’s perspective, the first step of any workflow that brings to a new journal publication starts with a formal submission of a manuscript performed by someone, hereinafter the author. This activity expresses, at the same time, interest on the topics of the journal and may acknowledge, indirectly, the quality of the journal itself – since authors (usually) would like to publish articles in a venue that they consider respectful and qualitatively worth for di↵ erent reasons (e.g., quality of reviews, journal impact factor, definite timing of the publishing process). Then, in the next step, i.e., the reviewing phase, the person (designated by the publisher) in charge of the quality of submitted material, hereinafter the editor, invites other people (hereinafter the reviewers) for assessing the quality of the submitted manuscript. The opinions returned by the reviewers to the editor are the fundamental input that the editor will use to decide upon the fate of the manuscript during the next step, i.e., the decision phase. Finally, if the manuscript have been considered worth of publication in the present form, the editor will acknowledge the author of the acceptance of his/her work – and the next steps of the workflow will be in charge of the publisher itself. Otherwise, if the article is not ready for being published, the editor either may ask for its rejection, thus finishing the workflow, or (s)he can return a list of issues to be addressed to the author in order to deserve publication. In this latter case, the revision phase will start and the author will revise the paper according to reviewers’ comments and editor’s suggestions, and thus the workflow will continue with a new submission phase.
The whole publishing workflow we have described (summarised in Fig. 2) can be formally represented by means of PWO. In the following excerpt (in Turtle [16]) we create an instance of the class pwo:Workflow as composed by a definite (but not specified, in this example) number of steps28: : workflow a pwo : Workflow ; pwo : hasFirstStep : step - one ; pwo : hasStep : step - two , : step - three , : step - four , ... .
In the next sections we show how to describe the first four steps of such
workflow by taking into account real publication data available in the Semantic
Web Journal Linked Data repository concerning [
Submission The first step of the workflow concerned the submission of a manuscript by one of its authors, in this case Paolo Ciccarese. Thus, the manuscript received the status of “submitted” and it was made available to the journal editor and the reviewers for the next step of the workflow. In order to describe all these aspects concerning the first step, we use several entities defined in the ontology patterns imported by PWO, as well as a number of other entities from another SPAR ontology, i.e., the Publishing Status Ontology (PSO)29 [15]. This is an ontology for describing the status held by a document or other publication entity at each of the various stages in the publishing process. In addition, existing entities of the Semantic Web Journal Linked Data repository (e.g., people and manuscripts) are reused in order to demonstrate the flexibility of PWO in working with other existing models and data, as shown as follows: : step - one a pwo : Step ; # Submission step pwo : involvesAction : submission - action ; tisit : atTime [ a ti : TimeInterval ; ti : hasIntervalStartDate "2013 -01 -21 T10 :08:28"^^ xsd : dateTime ; ti : hasIntervalEndDate "2013 -01 -21 T10 :08:28"^^ xsd : dateTime ] ; 28 Prefixes available at http://www.essepuntato.it/2014/wop/prefixes.ttl. 29 http://purl.org/spar/pso pwo : needs swj - node :432 ; pwo : produces : submitted - status ; pwo : hasNextStep : step - two . # The event in which one of the authors submits the manuscript : submission - action a taskex : Action ; dcterms : description " Paolo Ciccarese submits the paper " ; part : hasParticipant swj : paolo - ciccarese , swj - node :432 . # The new status ’ submitted ’ associated to the paper after the submission : submitted - status a pso : StatusInTime ; pso : isStatusHeldBy swj - node :432 ; pso : isAcquiredAsConsequenceOf : submission - action ; pso : withStatus pso : submitted ; tvc : atTime [ a ti : TimeInterval ; ti : hasIntervalStartDate "2013 -01 -21 T10 :08:28"^^ xsd : dateTime ] . 4.3
Reviewing
The step regarding the reviewing phase began with the activity of the editor,
Giancarlo Guizzardi, of looking for appropriate reviewers for the paper. Once
found, the reviewers were provided with the manuscript, reviewed it, and wrote
down their comments that were finally sent back to the editor. In order to
describe all the aspects concerning the second step, we use several entities defined
in additional SPAR ontologies, i.e., the Citation Counting and Context
Characterisation Ontology (C4O)30 [
ti : hasIntervalStartDate "2013 -04 -01 T05 :53:24"^^ xsd : dateTime ] . 4.4
Decision During the third step, the editor was responsible for the fate of the paper and provided a decision for it according to reviewers’ comments. Once formalised the decision, a decision letter was sent by email to the corresponding author (i.e., Paolo Ciccarese) and the status of the paper changed in then in “minor revision”. In the following excerpt we introduce the formalisation in PWO of the third step of the workflow: During the fourth step, the authors worked in order to revise the content of the previous version of the paper according to reviewers’ comments and editor’s suggestions. At the end of this step, the main result was the creation of a new version of the paper (i.e., swj-node:506 in our example) that had to be submitted in the next step. In the following excerpt we introduce the formalisation in PWO of the fourth step of the workflow: : step - four a pwo : Step ; pwo : hasNextStep : step - five ; # Revision step pwo : involvesAction : revision - action ; tisit : atTime [ a ti : TimeInterval ; ti : hasIntervalStartDate "2013 -06 -10 T17 :47:53"^^ xsd : dateTime ; ti : hasIntervalEndDate "2013 -07 -01 T05 :51:30"^^ xsd : dateTime ] ; pwo : needs swj - node :432 , : decision - letter , : review -1 , : review -2 ; pwo : produces swj - node :506 . : revision - action a taskex : Action ; dcterms : description " The authors revises the paper " ; part : hasParticipant swj - node :432 , : decision - letter ,
: review -1 , : review -2 , swj : silvio - peroni , swj : paolo - ciccarese . 5
In this paper we introduced the Publishing Workflow Ontology (PWO), i.e., an
OWL 2 DL ontology part of the Semantic Publishing and Referencing (SPAR)
Ontologies, which allows the description of publishing workflows in RDF. The
whole ontology is entirely based on existing ontology design patterns that allowed
us to model the various aspects of workflows in an appropriate and standardised
way. We showed a particular use of PWO for describing the first steps of a real
publishing workflow concerning the publication of an article of the Semantic
Web Journal, i.e., [
Although PWO had been thought in principle to describe publishing-related workflows, it has been developed on purpose as an ontology for the description of generic workflows. In future we plan to align it to other workflow-related models, e.g., PROV-O, the Research Object ontology and the other ontologies described in Section 2. In addition, we are currently studying the applicability of PWO in the legal and scientific domains. In particular, we plan to work on its use for describing workflows that concern the process of codification of the laws of the United States legislation and the series of computational or data manipulation steps in scientific applications. Building ontologies from textual resources: A pattern based improvement using deep linguistic information
Sami Ghadfi, Nicolas Béchet and Giuseppe Berio Abstract. Ontologies are a key component for several applications. Ontologies are often built by hand, but automatizing the process of ontology building has been and is even more recognized as very important for scaling and speeding up this process. However, several difficulties have been identified, some of them are quite fundamental. In this paper, we present our work for overcoming some of the fundamental difficulties. Our work resulted in improvements of an existing ontology building tool (Text2Onto). The contribution of our work consists in the creation of a flexible language (DTPL—Dependency Tree Patterns Language) for expressing patterns as syntactic dependency trees to extract semantic relations, and making an existing ontology building tool (Text2Onto) able to use them. DTPL allows to exploit deep linguistic information (related to coreference resolutions, conjunctions, appositions, passive verbal phrases, etc.) provided by deep syntactic analysis of the text, and also (in order to improve the accuracy of patterns) to express the exclusion of some dependency bindings in patterns.
Keywords: ontology building, semantic relation extraction, dependency tree patterns, deep linguistic information, Text2Onto, DTPL. 1
Introduction Ontologies are a key component for several applications. Ontologies are often built by hand, but automatizing the process of building ontologies has been and is even more recognized as very important for scaling and speeding up this process. Indeed, humans employ texts for providing information directly or indirectly, through the Web for instance. However, unstructured or semi-structured texts do not provide a welldefined semantic structure to be used by machines for reasoning tasks. Ontologies play therefore the key role for representing more explicitly the knowledge hidden in texts. As a consequence, ontologies can be made available for further applications.
Unfortunately, several difficulties concerning automatic ontology building have been identified, some of them are quite fundamental.
Additional arguments suggesting the need for developing complete “Ontology Building Support Systems” (OBSS) can be mentioned. Despite the fact that humans can recognize ontology artifacts from terms and sentences (which is enabled by their knowledge of the domain and the contexts on which terms are put together in sentences, suggesting semantic relations between terms), OBSS can supply the frequent terms and the contexts in which they appear, and systematically apply rules for suggesting how they are related to ontology artifacts. The magnitude of these terms and contexts makes their identification a task more suitable for machines than humans. In addition, ontologies evolve and these evolutions should be supported by automated systems.
For ontology building, there are two main challenges to be taken into account, which correspond to the basic building blocks of any ontology: ─ The extraction of concepts and their possible instances: it is a task in which we further distinguish between the extraction of the concept/instance itself, and naming it; ─ The extraction of semantic relations (hierarchical and non-hierarchical): it is a task in which we distinguish between identifying the relation occurrence (for example, identifying the relation occurrence “lion,animal”), and then identifying the seman- tic relation to which it belongs (“ lion,animal” is an occurrence of a hyponymy relation, the whole relation occurrence can be rewritten as is-hyponymof(lion,animal)).
Even if these two challenges are partially connected (i.e. the extraction of relations may impact on already extracted concepts and instances or may lead to additional concepts and instances), in this paper, we concentrate on the second one, i.e. semantic relation extraction. However, as better explained in Section 2, concept/instance extraction and relation extraction can be treated separately. This is also confirmed by the fact that tools used or usable for concept/instance extraction are developed independently for performing well identified tasks such as terminology extraction (possibly comprising disambiguation) and entity identification.
Semantic relation extraction methods can be categorized into two approaches:
Pattern based (mainly employing linguistic patterns), and Clustering based (mainly
employing clustering and statistical methods). We consider that linguistic patterns are
natural and concrete (because close to what humans (can) apply when they manually
build ontologies – by following methodologies and design patterns) for improving the
overall ontology building process, thus, we have focused on pattern based approaches
for relation extraction for the following detailed reasons:
─ Patterns represent frequent contexts in which term-pairs related by a given
semantic relation tend to appear—the reason for this observation is the way patterns are
constructed; very often, this construction begins by specifying seed examples
(term-pairs related by a given semantic relation), then looking for the contexts –in
sentences– in which they tend to appear together (these contexts can be sequences
or sets of words [
One can use the advantages of one category to overcome the drawbacks of the oth1 NP represents a noun phrase.
er. For instance, in [
However, effective usage of patterns within an OBSS remains an open research question. In Section 2, we present the existing methods for pattern-based relation extraction, and also their inherent difficulties (or limitations) preventing to get acceptable ontologies. Section 3 presents the contributions of the paper, i.e. (I) A method for enhancing OBSS with the ability to use deep linguistic information for relation extraction, (II) Making the generation of relations (including how relations can be named) through patterns very flexible, and (III) Implementing this method within an existing ontology building tool (Text2Onto). We finally conclude by summarizing the contributions and presenting perspectives in Section 4. 2
Difficulties Willing to semi-automatically build ontologies (or to support ontology building as best as possible) starting form texts, improvements can be concentrated on: ─ Improving the input text by modifying (substituting) the employed terms (e.g. for adopting a more standard terminology) and sentence structures, resolving ambiguities and co-references and so on; ─ Improving the quality of the final ontology by performing a quality assessment (e.g. using reasoning, if applicable, similarity (and other) measures) followed by relevant modifications; ─ Improving the process of building the ontology by improving the efficiency and effectiveness of the required tasks (i.e. relation extraction, concept/instance extraction, etc.).
In this paper, we focus on the third line of improvements, and more specifically, (as said in the Introduction) on relation extraction, because, as explained in section 2.1 below, concept/instance extraction can be performed independently from relation extraction. Section 2.2 presents the inherent difficulties in using pattern-based approaches for extracting semantic relations and related work.
Reasons for processing relation extraction and concept/instance extraction separately
Although concept/instance extraction and relation extraction are two partially dependent tasks, they can be treated separately. A formal justification can be presented as follows, on the top of a hypothetical ontology Description Logics formalization; whenever a relation (role) R is newly introduced, additional axioms involving existing concepts can be added. Generally speaking, introducing R can result in 3 situations: ─ Additional specification for an existing concept C e.g. C⊑ ∃R.⊤⊓∀R.⊤ or
C⊓∃R.⊤⊓∀R.⊤≠⊥; ─ Splitting an existing concept in subconcepts C’, C’’ such as, for instance,
C⊑C’⊓C’’, C’⊑∃R.⊤⊓∀R.⊤; ─ Creating a new concept C’ such that C’ ⊑∃R.⊤⊓∀R.⊤.
These few arguments should convince the reader that the extraction of relationships can be modularly managed as well. As a consequence, addressing only the difficulties concerning relation extraction is not a limitation; it even contributes in a well-defined modular way to improve concept/instance extraction. 2.2
Relation extraction methods using flat patterns and the inherent
difficulties
Pattern-based relation extraction methods often concern hyponymy and part-of
relations [
Another successful use of flat patterns is using reliable patterns to correct the
extraction results of less accurate patterns [
Java Annotation Patterns Engine (JAPE), a language of the open-source platform
General Architecture for Text Engineering (GATE2), has been the key language for
expressing flat patterns. With JAPE, flat patterns are expressed as transducers (using
macros, input and output annotations) to annotate sentences in the text that match the
pattern. Transducers are organized in queues corresponding to sentences in which, the
results (output annotations or macros) of one phase can be used as inputs by the next
one. A relevant usage of JAPE can be found in Text2Onto [
Using flat patterns has been successful for extracting semantic relations, but such patterns suffer from two major limitations that we point out hereafter.
The absence of deep syntactic information in flat patterns leads to misinterpretations when these patterns are matched to the text. Consider the following sentences: (s1) “The semantic formalization of knowledge has been achieved by the use of several tools such as ontologies, semantic networks and expert systems.”;; (s2) “Euclid, a great mathematician in his own right, showed to a king that there is no royal road to geometry.”. In these sentences, the comma can play two roles, i.e. a conjunction in (s1), or an introducer of apposition in (s2) (in (s2) the apposition is "great mathematician"). Another example of cases leading to misinterpretations is when the syntactic 2 A full documentation on GATE can be found at http://gate.ac.uk/documentation.html structure of the text (having impact on its semantic interpretation) cannot be efficiently and effectively captured by flat patterns. This includes cases like verb phrases expressed in active or passive form, or discontinuity cases (topicalization, etc.).
Flat patterns contain often unnecessary symbols for relation extraction, which often reduce the patterns coverage. It is the syntactic information conveyed by symbols that should be identified: in the example above (sentences (s1) and (s2)), what is interesting is to know whether the comma symbol represents a conjunction or an apposition. Another example is in the Hearst pattern P: " <Hypernym>(NP) including <Hyponym>(NP) ". The flat pattern P can be applied successfully to extract the hyponymy relation instance "specie is-hyponym-of organism" (r1) from the sentence (s3) “Organisms including species like flies, yeast, monkeys and worms have previously been put on diets and shown to have their life spans extended by 30 to 200%.”. H owever, if we insert the adjective diverse between including and species in the sentence (s3) (which results in the sentence (s4) “Organisms including diverse species like flies, yeast, monkeys and … ”), then P does not match anymore. However, the semantic relation (r1) should have been extracted from both sentences. Adding an adjective between the word including and the hyponym in P is not necessary (from the semantic view) to identify the hyponymy relation. 2.3
Dependency tree patterns
Fig. 2. (t4) A sub-tree of the syntactic dependency tree of the sentence (s4) The limitations of flat patterns mentioned in Section 2.2, can be overcome by using patterns that take into account deep linguistic information, i.e. syntactic dependency links3. We call these patterns Dependency Tree patterns (DT patterns). For example, the limitation involving the Hearst pattern P and sentences (s3) and (s4) mentioned in Section 2.2 can be overcome by the following DT pattern P2 " <Hypernym>(NP) -prep--> including(VBG4) --pobj--> <Hyponym>(NP) ". A matching between P2 and 3 The dependency links (mwe, prep, pobj, amod, etc.) mentioned in this paper are described in [13]. 4 VBG is a part of speech tag corresponding to a gerund or the present participle of a verb.
Acknowledgements This work was partially supported by the National Science Foundation under award 1017225 ”III: Small: TROn – Tractable Reasoning with Ontologies.” Ontology Patterns for Clinical Information Modelling
Catalina Martínez-Costa1, Daniel Karlsson2, Stefan Schulz1 1Institute for Institute for Medical Informatics, Statistics and Documentation,
Medical University of Graz, Austria 2Department of Biomedical Engineering, Linköping University, Sweden Abstract. Motivated by our experiences of representing clinical information using OWL DL, which often resulted in highly complex expressions, we propose the use of ontology content patterns to facilitate this task. They are based on a set of formal ontologies, constrained by the concepts and relations of a top-level one, which reduces arbitrariness in ontology design. We propose their application to information encoded by electronic health records specifications and ontology-based terminologies, in order to provide semantic interoperability across heterogeneously represented data, and to guide the creation of clinical models and detect semantic inconsistencies across them. We provide examples of their application to achieve the above mentioned tasks and discuss the limitations and further research issues.
Keywords: ontology content patterns, electronic health standards, SNOMED CT 1
Despite a wide-spread use of computers in clinical documentation, the semantic
interoperability of information kept in electronic health record (EHR) systems is
insufficient [
Existing EHR standards and medical terminologies were developed in isolation and
major problems exist when they are combined. Projects such as the HL7 TermInfo [
TermInfo provides a set of rules for the combined use of the HL7 information model and SNOMED CT; CIMI proposes a set of modelling patterns, defined as clinical models that are intended to act as guide for the creation of new ones. Clinical models constrain information model structures to represent particular data capture and communication use cases. In medicine it is often not possible to impose one universal data form, such as for recording diagnostic information. Thus, CIMI associates each clinical model with a set of iso-semantic models (models heterogeneously structured but with the same meaning), from which one is selected as the preferred one and mappings are established across them.
CIMI or HL7 based models that implement the TermInfo specification might work
well in isolation, but semantic interoperability issues arise when interacting with
others, which are not necessarily compatible, whilst the anticipation of all possible
isosemantic representations will lead to an explosion of models. The European network
SemanticHealthNet addresses this problem by providing clinical model information
structures with a set of expressions, based on a shared ontological framework. This
framework allows representing both (ontology-based) medical terminologies and
information models, and implements the classical distinction between ontology [
The inherent complexity of this representation is addressed by using semantic patterns as intermediate representations, which is the focus of this paper. 2
Background
EHR Structured Clinical Models
Several EHR standards and specifications propose representing clinical
information by using clinical models based on a reference information model (RM).
Clinical models, also known as archetypes (e.g. openEHR/ISO 13606 archetypes) [
In practice, the division line between ontologies and information models is often crossed both by ontologies (where they represent epistemic and temporal information aspects, such as “known present” or “past history of”) and by RMs and clinical models (where they carry their own ontology without reference to external standards, here the fact that it is a question). …}}}}}}}}
Fig. 1. (Left) ISO 13606 archetype excerpt to record questionnaire; (Right) Binding of an information structure to a SNOMED CT concept.
Ontology-based medical terminologies: SNOMED CT
Ontologies formally describe properties and relations of types of entities. Domainindependent categories, relations and axioms are typically provided by top-level ontologies [12], whereas the types of things that make up a domain are represented by domain ontologies. In the former one we find categories like Process, Material entity, Quality, etc., whereas in a clinical domain ontology we would find Diabetes mellitus type 1, Left index finger, or Aspirin, i.e. the classes of entities corresponding to the terms used in clinical documentation and reporting, and defined by the properties shared by all of their individual members.
Medical terminologies have evolved in the last years to include definitional knowledge about their terms, by using an ontological framework in order to help humans and computers to recognize the intended meaning of their terms, for proper coding of, retrieval of, and inferencing about biomedical data, as well as for maintenance of the terminology itself [13]. An example is SNOMED CT, a clinical terminology covering all aspects of clinical medicine, with about 300,000 representational units (called SNOMED CT concepts) and terms in several languages.
Due to the legacy of its predecessors, SNOMED CT does not only provide codes for clinical terms proper but also for contextual statements, which are often represented in information models. An example of this is the Situation with explicit context concept hierarchy (i.e. context model), in which we find terms such as Suspected deep vein thrombosis or No past history of venous thrombosis. We have largely harmonized the SNOMED CT content with basic top-level classes and relations of BioTopLite upper ontology [14] (e.g. btl:Process, btl:Quality, btl:Condition, btl:Situation, etc), in order to better distinguish clinical from information entities. Based on [15] we interpret SNOMED CT concepts from the clinical finding hierarchy as clinical situations and reinterpreted the SNOMED CT context model [16]. Fig. 2 shows the OWL DL representation of a post-coordinated1 expression that follows the context model and represents past history of diabetes. Past history is a temporal aspect that specializes the meaning of the finding diabetes mellitus. 1
Post-coordination describes the representation of a term using a combination of two or more of them (e.g. past history of clinical finding and diabetes mellitus) ‘past history of clinical finding (situation)’ and RoleGroup some ( (‘Associated finding (attribute)’ some ‘Diabetes mellitus (disorder)’) and (‘Finding context (attribute)’ some ‘Known present (qualifier value)’) and (‘Temporal context’ some ‘In the past (qualifier value)’) and (‘Subject relationship context’ some ‘Subject of record (person)’)) Fig. 2. OWL DL SNOMED CT representation of an expression based on the post-coordination of two terms (past history of clinical finding and diabetes mellitus linked by the linkage concept associated finding). Terms using italics represent ontology classes, bold face represents ontology object properties. 3
Methods A shared OWL DL [17] ontological framework is proposed that allows relating EHR information models with medical terminologies [18] in an unambiguous way. It is supported by a the use of semantic patterns in order to provide semantic interoperability across heterogeneously represented data and to guide the creation of clinical models and detect semantic inconsistencies across them.
The semantic patterns we propose represent recurrent clinical information modelling aspects and can therefore be considered ontology design content patterns applied to clinical information. They are inspired by the experience of modelling clinical information based on ontologies. As ontology patterns they help to reduce the arbitrariness that exists when representing clinical information, by using a set of OWL DL formal ontologies as standard modelling framework [19].
Two ontologies, the SNOMED CT ontology (prefix sct) and an information ontology (prefix shn) are rooted in the biomedical top-level ontology BioTopLite (prefix btl). The use of BioTopLite standardizes the ontology development process, by providing a set of logical axioms which constrain how both ontologies are related. We use SNOMED CT as common reference point for representing the healthcare domain. The information ontology provides a set of classes that represent contextual and temporal information aspects (e.g. diagnostic information, past history, provisional, etc.) and refer to the SNOMED CT concepts.
Each pattern can be considered a small ontology based on the previous framework, to be used as a building block for a particular modelling use case. For that, they can be specialized and composed by following similar principles to object oriented languages [20].
According to [21], content patterns are language-independent and should be encoded in a high order representation language. Nevertheless, their representation in a logic-based language allows the use of DL reasoning [22], which can be used to ensure the consistency of the patterns and to allow inference-related tasks. On the left side, Fig. 3 shows the graphical representation of a pattern that represents the past history of some patient clinical situation. The right side, shows a concrete instance of that pattern that represents the statement “Past history of diabetes mellitus”. Other examples of patterns are “Family history of clinical situation” or “Plan to perform some clinical process”.
Fig. 3. (Left) Graphical representation of the history-situation pattern; (Right) Instance of the history-situation pattern; Squares represent ontology classes and unidirectional arrows predicates enhanced by cardinality constraints.
Within SemanticHealthNet, we have elaborated two representations of semantic patterns: an OWL 2 DL and a RDF [23] representation. The OWL-based representation describes a pattern as a set of logical axioms. Table 1 shows the OWL rendering of the history-situation pattern as pieces of information (shn:InformationItem) that are acquired by performing some clinical process (shn:ClinicalProcess) and that refer to clinical situations (shn:ClinicalSituation) of a given type (if any), which happened in the past (sct:InThePast). Additionally, it allows expressing epistemic information aspects (shn:InformationAttribute) that indirectly refer to the situation (e.g. severe, present, etc.).
shn:InformationItem and shn:isAboutSituation only shn:ClinicalSituation and btl:isOutcomeOf some shn:ClinicalProcess and shn:hasInformationAttribute some shn:InformationAttribute and shn:hasInformationAttribute some sct:InThePast and shn:hasInformationAttribute some sct:FindingContextValue
Table 2 shows the RDF representation, which consists of a set of Subject-PredicateObject (SPO) triples. Both representations are connected as follows: The subject and object parts of a triple correspond to ontology classes, and the predicates to ontology expressions. Table 3 provides the OWL DL translation of the RDF predicates. This allows the implementation of automatic translations from a ‘closer to user’ RDF representation into a representation in OWL DL, which would require a more in-depth understanding of DL syntax and semantics. In the following we will describe the use of semantic patterns regarding EHR clinical models and ontology-based terminologies as SNOMED CT.
shn:InformationItem ´describes situation´ shn:ClinicalSituation shn:InformationItem ´results from process´ shn:ClinicalProcess shn:InformationItem ´has attribute´ shn:InformationAttribute shn:InformationItem ´has temporal context´ sct:InthePast shn:InformationItem ´has situation context´ sct:FindingContextValue
OWL DL expression SUBJ subClassOf shn:isAboutSituation only OBJ SUBJ subClassOf btl:isOutcomeOf some OBJ SUBJ subClassOf shn:hasInformationAttribute some OBJ SUBJ subClassOf shn:hasInformationAttribute some OBJ
SUBJ subClassOf shn:hasInformationAttribute some OBJ
The role of semantic patterns regarding EHR clinical models and medical domain ontology-based terminologies
Assuming that a limited set of top-level semantic patterns that can be specialized and composed is sufficient to represent a great variety of clinical information, we propose the use of semantic patterns as proxy to the semantic representation of clinical information encoded by EHR structured clinical models and ontology-based medical terminologies. They act as a template, with fix and variable parts, and guide the mapping process in which the correspondences between information model structures and their values are defined with regards to the ontology. Dashed arrows in Fig. 4 indicate the correspondences between the clinical model from Fig. 1 and the historysituation pattern.
As observed, the pattern is applied to both, the SNOMED CT term used as binding and the clinical model information structures. Three correspondences have been provided. Two between the CLUSTER[at0002] binding and the pattern triples that represent the situation and its temporal context. Diabetes mellitus is placed as subclass of shn:ClinicalSituation. One between the value of ELEMENT [at0003] and the pattern triple that represents if the situation is present (sct:KnownPresent) or absent (sct:KnownAbsent). Both are represented as subclasses of sct:FindingContextValue, and will be selected depending of the value of the model instance (True or False). 417662000 | past history of clinical finding | : { 246090004 | associated finding | =
73211009 | diabetes mellitus | } ENTRY[at0000] matches { -- Question group items matches{ CLUSTER[at0001] matches { -- Question group items matches {
CLUSTER[at0002] matches { -- Question items matches { terminology binding
ELEMENT[at0003] matches{ -- Answer value matches {
BL matches {True, False} … }}}}}}}} Fig. 4. (Left) ISO 13606 archetype and SNOMED CT binding to record the question “past history of diabetes” (Y/N); (Right) Graphical representation of the history-situation pattern 4
Results
In the following we will describe the potential of semantic patterns for each of the tasks introduced in the Methods section. We will use the history-situation pattern as example.
We will use the history-situation pattern to provide semantic interoperability across two past history data instances captured by two heterogeneous fictitious applications used at a GP consultation and at a hospital. Fig. 5 shows their interfaces. They have been designed attending to different requirements and therefore record the information at different levels of detail. At the hospital (right), the specialist records additional information about the patient past situation (i.e. cause and severity). However, the GP only records the situation itself (left).
Fig. 5. (Left) Past history recording at the GP; (Right) Past history recording at the specialist. Each of the above applications is based on a different ISO 13606 clinical model. The GP application is based on the questionnaire model introduced in Section 2.1. The left part of Fig. 6 shows the model used by the hospital application. Both are different in terms of structure but not syntax, since both implement the same standard.
In order to access information recorded by both applications, independently of their source representation, the correspondences between each clinical model and the history-situation pattern are defined. Fig. 4 depicted the correspondences between the questionnaire model and the pattern. Following, dashed arrows in Fig. 6 show the correspondences for the hospital model. This model allows recording the severity of the past disease and its cause, requiring the use of the situation pattern, by composition. The situation pattern, allows providing more detail information such as when it occurs, where, associated situations, etc.
Once the correspondences between the models and the patterns are established, when the former ones are instantiated with patient data, the instances of the patterns are also created, in a similar way to the one shown in Fig. 3. If OWL DL instances are created, it is possible to perform homogeneous queries on instances from both applications and retrieve their results [24].
ENTRY[at0000] matches {-- Past history items matches{
ELEMENT[at0001] matches{ -- Condition value matches {
CODED_TEXT matches {*} } CLUSTER[at0002] matches { -- Details items matches {
ELEMENT[at0001] matches{ -- Cause value matches {
CODED_TEXT matches {*} }}} ELEMENT[at0001] matches{ -- Severity value matches {
CODED_TEXT matches {*} } }} Fig. 6. ISO 13606 clinical model that records past history of condition, its cause and severity Besides, the use of the ontology framework and DL reasoning allows performing queries at different granularity level: E.g. “Information about all patients with past history of some endocrine disease”, without specifying whether diabetes or a different one. 4.2
Semantic patterns guide the creation of clinical models and detect semantic inconsistencies
Semantic patterns can guide the development of new clinical models if the latter are created by following the constraints dictated by a set of limited top-level patterns.
Top-level patterns are based on a set of generic ontology classes and predicates that can be specialized and composed by following the ontology constraints. These constraints can be used to determine which elements include in a clinical model or in a terminology binding.
As a difference with clinical models, where their elements are only structurally related (e.g. list, tree, etc.), within patterns they are connected by semantic relationships (e.g. shn:isAboutSituation, btl:isOutcomeOf, etc.). These relationships can be used to guide the decision of the elements to include in a model, reducing the existing arbitrariness. Now this is mainly a non-constrained modeller decision that might lead to the creation of non-interoperable models even for the same use case.
If semantic patterns are not applied at clinical models design time, they still can be used to detect semantic inconsistencies across them. As an example, Fig. 7 shows an excerpt of a CIMI model that records observation results. It records: (i) what is observed, ELEMENT[at0001] (e.g. color of the eye); (ii) the reason to perform the observation, ITEM[at0002] (e.g. problem wearing contact lens); (iii) the method used to observe, ITEM[at0003] (e.g. eye examination); (iv) the status of the observation, ELEMENT[at0004] (e.g. performed, planned); and (v) the priority to perform the observation, ELEMENT[at0005] (e.g. high, normal).
CLUSTER[at0000] matches { -- Observable item matches {
ELEMENT[at0001] occurrences matches {1} matches { -- Name
value matches { TEXT matches {*}}} ITEM[at0002] occurrences matches {0..*} -- Reason ITEM[at0003] occurrences matches {0..*} -- Method ELEMENT[at0004] occurrences matches {0..1} matches { -- Status
value matches { CODED_TEXT matches {*}}} ELEMENT[at0005] occurrences matches {0..1} matches { -- Priority
value matches { TEXT matches {*}}} }} Fig. 7. Excerpt of the CIMI model (CIMI-CORE-CLUSTER.observable.v1.0.0) to record observation results Fig. 8 shows another CIMI model that records observation requests and references the above model by composition (keyword “use_archetype”). Besides, it also references a model to record observation actions. Within this last model we have found a content overlapping with the observation result one, since it also provides elements for recording the reason, method, status and priority of the observation.
ENTRY[at0000.1] matches { -- Observation link matches {LINK[at0.1] occurrences matches {0..*} -- Associated request} data matches { use_archetype CLUSTER [CIMI-CORE-CLUSTER.observable.v1] -- Observable use_archetype CLUSTER [CIMI-CORE-CLUSTER.finding.v1] -- Results use_archetype CLUSTER [CIMI-CORE-CLUSTER.observe_action.v1] -- Observe action … Fig. 8. Excerpt of the CIMI model (CIMI-CORE-ENTRY.observation.v4.0.0) to record an observation request and its result
Semantic patterns could avoid such an overlapping situation, by providing formal modelling guidelines, based on the ontological framework, to distinguish across what is observed, the observation procedure and the result of the observation.
Additionally, as already mentioned, they can help to guide or detect inconsistencies regarding terminology bindings. For instance, the pattern logic axiom (shn:InformationItem and shn:isAboutSituation only shn:ClinicalSituation), relates an information entity (i.e. shn:InformationItem) with a clinical entity (shn:ClinicalSituation) and the latter is equivalent to SNOMED CT clinical findings. Therefore, if a model information structure is mapped to that axiom, its value is only valid if it is of the type clinical finding.
When clinical models are instantiated with patient data, semantic patterns can also be used to check that the data entered complies with the constraints defined at the model level. 5
Discussion and conclusions
In this work we have proposed semantic patterns as ontology design content patterns applied to the representation of clinical information. They were motivated by our experiences of representing clinical information using OWL DL, which often resulted in highly complex expressions.
The EHR standards community has put a lot of effort in providing standardized means to represent the EHR. However, the complexity of the medical domain and their heterogeneous data capture and re-use needs does not make it easy. One of the reasons might be the high degree of freedom provided when modelling clinical information, which is mainly formally constrained in terms of structure but without considering the meaning of what is being represented.
Aware of this gap, and concerned about the need of providing standardized modelling means, we propose an ontological framework, in order to represent both information and medical entities, constrained by a top-level ontology which reduces arbitrariness in ontology design. Semantic patterns are based on this framework and therefore constrained by their concepts and relations. In [25], the advantages of using a top-level ontology for creating ontology design content patterns were described, stating that it provides it with an existing backbone structure and well-defined relations.
Semantic patterns provide a more intuitive representation and standardize their development process, yet allowing flexibility through specialization and composition. We have proposed their representation in OWL DL and in RDF. The former one allows logical reasoning and therefore more advanced exploitation of information, although it might be more difficult to implement in a real system, due to performance issues. In the latter case, the RDF representation although less expressive and therefore more limited in terms of information exploitation, might be more adequate. Correspondences between both representations exist, what might allow using the most suitable one for each use case.
In this work we have demonstrated how semantic patterns can be applied to EHR clinical models and ontology-based terminologies (1) to provide semantic interoperability across heterogeneously represented data and (2) commented their potential use to guide the creation of clinical models and detect semantic inconsistencies across them.
By looking at the content patterns available at the NeOn repository [26], we did not find specific patterns for the modelling of clinical information. However, patterns such as the agent-role or the action ones can be applied.
There are numerous new issues that arise from the use of semantic patterns for EHR modelling that still have to be investigated. These include the selection of the right set of patterns to be used for modelling specific pieces of clinical information, who would create and maintain the patterns and who would manage and validate them.
Other issues must be further investigated, such as providing evidence that a set of top-level semantic patterns for modelling clinical information can be rather small, with increasing complexity and expressiveness coming from specialization and composition. So far we have only worked with limited modelling examples and we need more evidence of the real benefit of using patterns; what is hard to obtain without appropriate tools that implement them.
Further research should include the potential of semantic patterns for detecting semantic inconsistencies across existing clinical models, considering their specialization, composition and cardinality constraints. Languages such as SPIN [27] or RDF shapes [28] could be helpful for their representation and are subject of our research.
Acknowledgements. This work has been funded by the SemanticHealthNet Network of Excellence within the EU 7th Framework Program, Call:FP7-ICT- 2011-7, agreement 288408. http://www.semantichealthnet.eu/ 9. Beale, T. Archetypes: Constraint-based domain models for future-proof information systems. Eleventh OOPSLA Workshop on Behavioral Semantics: Serving the Customer. Seattle, Washington, USA: Northeastern University; 2002:16-32. 10. ISO EN13606 Electronic Health Record Communication Part 2: Archetype interchange specification. CEN TC/251, 2008 11. Dolin, R.H., Alschuler, L., Boyer, S., et al.: The HL7 Clinical Document Architecture, release 2. J Am Med Inform Assoc 2006;13:30-39 12. Schulz, S., Jansen, L.: Formal ontologies in biomedical knowledge representation. Yearbook of Medical Informatics 2013;8(1):132-46 13. Cimino, J.J., Zhu, X.: The practical impact of ontologies on biomedical informatics. Yearb
Med Inform [Internet] .2006;124–35. http://www.ncbi.nlm.nih.gov/pubmed/17051306 14. Schulz, S., Boeker, M.: BioTopLite: An Upper Level Ontology for the Life Sciences. Evolution, Design and Application. Informatik 2013. U. Furbach, S. Staab; editors(s). IOS Press; 2013 15. Schulz, S., Rector, A., Rodrigues, J.M., Spackman, K.: Competing interpretations of disorder codes in SNOMED CT and ICD. AMIA Annu Symp Proc. 2012;2012:819-27. Epub 2012 Nov 3. PubMed PMID: 23304356; PubMed Central PMCID: PMC3540515. 16. Martínez-Costa, C., Schulz, S.: Ontology-based reinterpretation of the SNOMED CT context model. Proceedings of the 4th International Conference on Biomedical Ontology.
CEUR Workshop Proceedings 2013; 1040:90-95. 17. W3C OWL working group. OWL 2 Web Ontology Language, Document Overview. W3C Recommendation 11 December 2012. http: //www.w3.org/TR/owl2-overview (accessed August 2014). 18. Schulz, S., Martínez-Costa, C.: How Ontologies Can Improve Semantic Interoperability in Health Care. In: Riaño, D; Lenz, R; Miksch, S; Peleg, M; Reichert, M; Teije, A editors(s). Lecture Notes in Computer Science. 8268: Berlin Heidelberg: Springer International Publishing; 2013;1-10 19. Presutti, V., Gangemi, A.: Content Ontology Design Patterns as Practical Building Blocks for Web Ontologies. In Proceedings of the 27th International Conference on Conceptual Modeling (ER '08), Springer-Verlag 2008, Berlin, Heidelberg, 128-141. 20. Gangemi, A.: Ontology Design Patterns for Semantic Web Content. In Proceedings of the
Fourth International Semantic Web Conference, 2005:262-276 21. Gangemi, A., Presutti, V.: Ontology Design Patterns. In: Staab, S., Studer, R. (eds.) Handbook on Ontologies, Second edition, pp. 221 – 243, Springer (2009) 22. Baader, F., Calvanese, D., McGuinness, D.L., et al. The Description Logic Handbook,
Cambridge University Press, New York, NY; 2007 23. W3C Resource Description Framework (RDF). http://www.w3.org/RDF/ (accessed August 2014). 24. Martínez-Costa, C., Schulz, S.: Ontology Content Patterns as Bridge for the Semantic Representation of Clinical Informatics. Applied Clinical Informatics eHealth special issue. 2014; 5(3): 660-669 25. Seddig-Raufie, D., Jansen, L., Schober, D., Boeker, M., Grewe, N., Schulz, S. Proposed actions are no actions: re-modeling an ontology design pattern with a realist top-level ontology. J Biomed Semantics. 2012;5(Suppl 2):S2. 26. NeOn repository Ontology Design Patterns.org (ODP) http://ontologydesignpatterns.org (accessed August 2014). 27. SPARQL Inference Notation (SPIN) http://spinrdf.org/ (accessed August 2014). 28. Shape Expressions 1.0 Definition. http://www.w3.org/Submission/2014/SUBM-shex-defn20140602/ (accessed August 2014).
An Ontology Design Pattern for Material
Transformation Charles Vardeman1, Adila A. Krisnadhi2,3, Michelle Cheatham2, Krzysztof
Janowicz4, Holly Ferguson1, Pascal Hitzler2, Aimee P. C. Buccellato1, Krishnaprasad Thirunarayan2, Gary Berg-Cross5, and Torsten Hahmann6 1 University of Notre Dame, 2 Wright State University, 3 University of Indonesia 4 University of California, Santa Barbara 5 Spatial Ontology Community of Practice (SOCOP), USA
6 University of Maine Abstract. In this work we discuss an ontology design pattern for material transformations. It models the relation between products, resources, and catalysts in the transformation process. Our axiomatization goes beyond a mere surface semantics. While we focus on the construction domain, the pattern can also be applied to chemistry and other domains. 1
Introduction &
Motivation
According to the United Nations, the construction industry and related support
industries are leading consumers of natural resources. Consumption of these
natural resources result in the emission of energy, and thus carbon and other
greenhouse gases, which are then“embodied” in the consumption process.
Efforts have been made to quantify these emissions through measures of embodied
energy, carbon and water but are lacking due to poor quality of data sources,
lack of understanding of uncertainty in the data, lack of geospatial attributes
necessary for proper calculation of embodied properties, understanding regional
and international variation in data, incompleteness of secondary data sources
and variation in manufacturing technology that lead to significant variation
calculated values [
Transportation of a manufacturing component from location to location and
the energies associated with that transportation can be modeled via the
Semantic Trajectory pattern (STODP) [
In this work we discuss the development of a Material Transformation
pattern2 to contextualize this transformation process from raw components and the
required equipment to a final manufactured artifact. Chaining this pattern with
STODP will facilitate understanding of a complete manufacturing process from
raw material extraction to assembly of all components needed for that product.
The presented work was done in two 2-day sessions involving domain experts
from architecture, computational chemistry, and geography, as well as ontology
engineers at GeoVoCampDC20133 and GeoVoCampWI20144. We present a full
axiomatization that goes beyond mere surface semantics [
Fig. 1. Material Transformation Pattern with Energy Information that every Resource, Catalyst and Product is some MaterialType, while (6) and distinguishes Resource from Catalyst. Axiom (3) and (4) assert that a MaterialTransformation occurs in a spatial Neighborhood5 and a time interval, modeled using the Interval class from the W3C’s OWL Time ontology6.
MaterialTransformation v 9 hasInput.Resource MaterialTransformation v 9 hasOutput.Product MaterialTransformation v 9 occursInNeighborhood.Neighborhood MaterialTransformation v 9 occursAtTimeInterval.time:Interval Resource t Catalyst t Product v MaterialType Resource u Catalyst v ?
9 hasInput.Resource v MaterialTransformation
MaterialTransformation v 8 hasInput.Resource 5 Neighborhood provides a toplogical definition for specifing nearness. This could be specified in di↵ erent ways such as using positional coordinates, a bounded area on a map, or a named region such as a place, city or factory. 6 http://www.w3.org/TR/owl-time/ We express changes occurring within a material transformation, using first-order logic, that it has an input that is not part of the output (7); and an output that is not part of the input, in a formula analogous to (7).
8 x(MaterialTransformation(x) ! 9 y(hasInput(x, y) ^ ¬hasOutput(x, y)))
These formulas, however, cannot be expressed in the OWL framework, but
there are extensions of DL that can express them. For example, using boolean
constructors on properties [
MaterialTransformation v 9 (hasInput u ¬hasOutput).> Meanwhile, for the remaining properties of the core part of the pattern, we assert the guarded domain and range restrictionsas exemplified for the hasInput property in (8) and (9) below. Such guarded restrictions are preferable over the unguarded versions (i.e., of the form dom(P ) v A and range(P ) v B) as they introduce weaker ontological commitments and thus foster reuse.
For the scenario where we need to calculate the embodied energy in the output of a material transformation, we can extend the pattern with additional energy information as depicted in Fig. 1. In the axiomatization, we then assert that a MaterialTransformation needs some Energy (10), while each material type has some embodied energy (11). Energy itself is abstracted as an instance of the Energy class, which has some energy value and unit.
MaterialTransformation v 9 needsEnergy.Energy
MaterialType v 9 hasEmbodiedEnergy.Energy
Energy v 9 hasEnergyValue.EnergyValue EnergyValue v 9 hasEnergyUnit.EnergyUnit
u 9 asNumeric.xsd:double EnergyUnit v 9 asLiteral.xsd:string Embodied energy in the output as a result of a material transformation can be calculated by aggregating embodied energy of the input and catalyst, together with energy requirement of the material transformation itself. This cannot be done within OWL, but is relatively straightforward to implement in the application as all the necessary information are easily retrievable from the populated pattern. Furthermore, if the application allows updates on the data populating the pattern, we can chain two instantiations of this pattern and include STODP. 3
Conclusion and Future Work Although it is beyond the scope of the present work, the Material Transformation pattern should be su ciently generic to describe other types of transformation processes ranging from chemical reactions to creation-annihilation events in high energy physics. We believe the pattern to be of general use to broader product life cycle inventories outside the construction domain.
Acknowledgements. We are grateful for the inputs from Lamar Henderson, Deborah MachPherson, Laura Bartolo, and Damian Gessler to improve the pattern. Vardeman, Buccellato and Ferguson would like to acknowledge funding from the University of Notre Dame’s Center for Sustainable Energy, School of Architecture, College of Arts and Letters and Center for Research Computing in support of this work. Gary Berg-Cross acknowledges funding from the NSF grant 0955816, INTEROP-Spatial Ontology Community of Practice. Vardeman would like to acknowledge funding from NSF grant PHY-1247316 “DASPOS: Data and Software Preservation for Open Science.” Adila Krisnadhi, Michelle Cheatham, and Pascal Hitzler acknowledge support by the National Science Foundation under award 1017225 “III: Small: TROn – Tractable Reasoning with Ontologies.” An Ontology Design Pattern for Activity Reasoning Amin Abdalla1, Yingjie Hu2, David Carral3, Naicong Li4, Krzysztof Janowicz2 1 Institute for Geoinformatics,Vienna University of Technology, Austria 2 Department of Geography, University of California Santa Barbara, USA 3 Kno.e.sis Center, Wright State University, USA
4 University of Redlands, USA
Abstract. Activity is an important concept in many fields, and a number of
activity-related ontologies have been developed. While suitable for their
designated use cases, these ontologies cannot be easily generalized to other
applications. This paper aims at providing a generic ontology design pattern to model
the common core of activities in different domains. Such a pattern can be used as
a building block to construct more specific activity ontologies.
1 Introduction
Activity is an important research topic in many fields, such as artificial intelligence,
human geography, transportation research, psychology, and human-computer interaction.
As a result, there are a number of conceptual models that attempt to capture the
semantics of activities. Existing activity ontologies (e.g.,[
Two main perspectives on activity modeling can be identified from the literature: a
spatiotemporal-centric and a workflow-centric perspective. The first one treats activities
as a set of temporally-ordered entities in space and time. This perspective has often
been found in the literature on time geography [
The second perspective treats activities as a workflow. This view is often found
in planning-related applications, in which preconditions and effects of activities are
important. Representative examples include the Planning Domain Definition Language
(PDDL), or the Process Specification Language (PSL-core) [
This work aims at developing a more generic ontology design pattern (ODP) that
incorporates parts of both perspectives. Such a generic ODP can be employed as a
building block or strategy for designing more specific activity ontologies. While the
PROV ontology6 also models activities and the associated entities, it focuses on
recording the changes of entities and the representation of provenance information. Given the
5 http://ontologydesignpatterns.org
6 http://www.w3.org/TR/prov-o/
fast development of ubiquitous sensor networks and the Internet of Things, more data
about human activities are becoming available. These rich amount of data enable new
applications, such as activity-based personal information management [
Deriving an ontology design pattern requires a generic use case which can capture
the recurring problems in different application domains [
Pattern Description and Formalization
This section presents the activity pattern by discussing the more interesting classes,
properties, and axioms. Description Logics (DL) notation has been used to present
the axioms. To encode the pattern, we use the logic fragment DLP9 as defined in
[
Fig. 1. A schematic view of the Activity ODP.
Activity: In accordance with PSL, our pattern allows activities to potentially consist of several component activities (which can yet again be associated with further component activities). In this way, aggregation over a set of activities into higher level activities is possible. We make use of the properties hasPart and isPartOf to formally denote this relation. These two roles, which are inverse roles with respect to each other, are declared both transitive and reflexive. Also, the Activity class is declared as disjoint with the classes of Requirement and Outcome. We make use of the following axioms to enforce these characteristics 7 hasPart ⌘ isPartOf hasPart hasPart v hasPart
> v 9 hasPart.Self
Requirements and Outcomes: Dependency relations are important to model multiple activities. To capture these relations, we make use of Requirements and Outcomes, i.e., the required inputs and resulting outputs of any given activity. In some cases, the outcome of one activity might be a requirement of another. If this is the case, we say the former activity precedes the latter, assuming that an outcome is only produced after an activity was finished. Thus precedes does depict a logical relation that requires temporal precedence. We define the properties precedes and isPrecededBy as inverse roles, and declare them as transitive and irreflexive.
hasOutcome isRequirement v precedes
Agent: The class of foaf:Agent from the FOAF ontology8 has been employed to represent an actor or an autonomous agent whose behavior is intentional. The foaf:Agent class can also be substituted by its sub classes, such as foaf:Group or foaf:Person, and therefore allows ontology engineers to further specify what type of participant is involved in the activity. The hasParticipant property depicts the involvement of an foaf:Agent in an activity.
Spatiotemporal Relations: The spatiotemporal information associated to activities is captured through the following properties.
– takesPlaceAt. This property indicates the place where an activity takes place. It can be used as a hook to align to other ODPs, e.g., the POI pattern. – hasStart. This property indicates the time an activity starts. – hasEnd. This property indicates the time an activity ends. – hasDuration. This property indicates the time period that an activity lasts. The value of duration should be equal to the difference between the start and end time of an activity.
It is worth to note that the above spatiotemporal properties can be used to represent not only past activities (i.e., activities that have already happened) but also future activities (i.e., activities scheduled in the future).
The proposed activity ODP also distinguish two types of activities, namely Fixed
Activity and Flexible Activity, as defined in the time geography literature [
9 hasStart.> u 9 hasEnd.> v FixedActivity 9 hasStart.> u 9 hasDuration.> v FixedActivity 9 hasEnd.> u 9 hasDuration.> v FixedActivity
FlexibleActivity u 9 hasStart.> u 9 hasEnd.> v ? FlexibleActivity u 9 hasStart.> u 9 hasDuration.> v ? FlexibleActivity u 9 hasEnd.> u 9 hasDuration.> v ? (6) (8) (10) This paper proposed a generic ODP to capture the common core of activities in different domains. Specifically, it incorporates two perspectives towards activity modeling, namely the spatiotemporal perspective and the workflow perspective, which can often be found in existing work. Such a pattern can be used as a building block to design more domain specific ontologies.
Acknowledgement This work is supported by the NSF under award 1017255 and "La Caixa" Foundation. References