The Publishing Workflow Ontology (PWO)

Abstract

In this paper we introduce the Publishing Workflow Ontology (PWO), i.e., an OWL 2 DL ontology for the description of 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 publishing workflows. In addition, we present two possible application of PWO in the publishing and legislative domains.

1. Introduction

Keeping track of publication processes is a crucial task for publishers. This action 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 Food1

¹

Semantic Web Dog Food: http://data.semanticweb.org.

and the Semantic Web Journal,2

²

Semantic Web Journal: http://semantic-web-journal.com.

as RDF statements in the Linked Open Data Cloud, that 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, a flexible model for describing these data, developed according to guidelines for guaranteeing its reusability in different domains, is also needed. Having these types of data publicly available and described according to such model would result in:

• increasing transparency of the (publishing) process;

• enabling the use of such data for statistical analysis;

• facilitating the integration, alignment and adaptation of both the data and the model according to the needs and constraints of different domains (publishing, academic conferences, research funding, etc.).

In this paper, which extends our work presented at the 5th International Workshop on Ontology and Semantic Web Patterns [9],3

³

This paper was selected by the members of the organising committee as one of the best papers of the workshop for being part of a fast-track submission to the Semantic Web journal’s Special Issue on Ontology Design Patterns. However, more than proposing a new pattern, our work extends the published workshop paper and focuses on the reuse of design patterns for developing an ontology for publishing workflows. The additional material provided in this revised version concerns: the description of the design pattern adopted, which has been extended in order to clarify several parts and that now includes a precise specification of the requirements for such model; the extension of the section describing our ontology, that now includes some statistics and definitions that were not present in the original article, as well as the introduction of several new parts of the ontology that have been added as consequence of reviews and comments we received during the workshop; the introduction of a new example of use in the legislative domain, and an example of SPARQL queries for answering some relevant questions within the publishing domain.

we introduce the Publishing Workflow Ontology (PWO), that we developed in order to reach the aforementioned goals. This ontology is one of the Semantic Publishing and Referencing (SPAR) Ontologies4

⁴

SPAR Ontologies website: http://www.sparontologies.net.

[20] (which have been created for the description of different 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. In Section 5 we show how to use PWO for modelling data related to the publication process of an article of the Semantic Web Journal and to the codification process of laws in US legislation. Finally, in Section 6 we conclude the paper sketching out some future works.

2. Workflows and the Semantic Web

The use and managing of workflows is a relevant aspect in different applicative domains. For instance, formalised approaches for workflow definitions and executions have been adopted in industrial applications for managing and delivering products,5

⁵

SDL LiveContent 2014: http://docs.sdl.com/LiveContent/content/en-US/SDL%20LiveContent%20full%20documentation-v1/GUID-867B6863-ADAD-40C9-A3F7-775FE29FAFF3.

XML-based scholarly publishing [19], and Wiki-oriented publication mechanisms.6

⁶

http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Publication+Workflow+Application.

In the last years the Semantic Web community have also 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 Wf4Ever (STREP FP7-ICT-2007-6 270192)7

⁷

Wf4Ever project homepage: http://www.wf4ever-project.org.

[12]. This project addresses challenges related to the preservation of scientific experiments through the definition of models and ontologies for describing scientific experiments, to the collection of best practices for the creation and management of Research Objects8

⁸

Research Object website: http://www.researchobject.org.

[2], and to the analysis and management of decay in scientific workflows.

As already stated, one of the outcomes of the project has been the proposal for workflow-centric Research Objects [1], i.e., an OWL ontology9

⁹

Research Object OWL ontology: http://purl.org/wf4ever/ro.

for linking together scientific workflows, the provenance of their executions, interconnections between workflows and related resources (e.g., datasets, publications, etc.), and social aspects related to such scientific experiments.

Another interesting proposal for describing workflows is the work done by Garijo and Gil [11]. In this work, they describe a framework to publish computational workflows, which includes the specification of a particular OWL ontology, i.e., the Open Provenance Model for Workflows (OPMW),10

¹⁰

Open Provenance Model for Workflows: http://www.opmw.org/ontology/.

for the description of workflow traces and their templates. Along the lines of the aforementioned work, the same authors recently published the Ontology for Provenance and Plans (P-Plan).11

¹¹

Ontology for Provenance and Plans: http://purl.org/net/p-plan#.

P-Plan is an OWL 2 DL ontology that extends the Provenance Ontology [16] in order to represent the plans that guided the execution of scientific processes, describing how such plans are composed and their correspondence to provenance records that describe the execution itself.

Finally, among the other proposals for describing workflows, it is worth mentioning the OWL ontology proposed by Sebastian et al. [28] for describing generic workflows, which reuses existing ontologies such as the Change and Annotations Ontology (ChAO) [18], and the SCUFL2 Core ontology12

¹²

http://ns.taverna.org.uk/2010/scufl2.

that has been used to describe workflows in Taverna,13

¹³

http://www.taverna.org.uk.

an open source and domain-independent Workflow Management System [29].

The first stable version of the Publishing Workflow Ontology (PWO) has been released in 2010 as part of the SPAR Ontologies. It was pattern-based but it did not include any of the entities introduced in the aforementioned ontologies, since some of them were (as far as we knew at the time) either not available or not released in stable form. Some of the modelling ideas presented in papers have been considered and in many cases followed.

Of course, since the first release, PWO has been extended and the version presented in this article is the result of such evolution. However, in order to foster its reuse and interoperability with the aforementioned OWL ontologies, an initial alignment path with PWO has been created and it is available online.14

¹⁴

http://purl.org/spar/pwo-alignment.

3. Foundational material: Design patterns

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 existing modelling solutions. In order to gather minimal requirements, we take into account both general definitions of workflows, and existing workflow models, as, e.g., generalised in [27]. Minimal requirements will then be used to retrieve or create appropriate ontology design patterns [10], which have proved to substantially improve ontology design quality [3], due to their ability to address the semantics of requirements, and to their modularity.

Definitions are quite convergent, e.g., the Oxford Dictionaries site defines workflow as follows:

“The sequence of industrial, administrative, or other processes through which a piece of work passes from initiation to completion.”15

¹⁵

http://www.oxforddictionaries.com/definition/english/workflow.

From this definition it is possible to identify some important characteristics (listed as R1, …, Rn requirements) of any workflow, i.e., the fact that:

• it involves a sequence of processes [R1];

• each process allows one to initiate and then complete a piece of work during a specifiable time interval [R2].

The definition of the SearchCIO website is still more specific:

“Workflow is a term used to describe the tasks, procedural steps, organisations or people involved, required input and output information, and tools needed for each step in a business process.”16

¹⁶

http://searchcio.techtarget.com/definition/workflow.

From this definition we can spot other crucial aspects:

• the structure of a workflow is organised in procedural steps [R3];

• each step describes tasks [R4];

• each task is performed by organisations or people [R5];

• each task requires some input information in order to produce an output [R6].

Control flow patterns [27] address additional requirements on the possible structure of the steps:

• sequencing [R7];

• parallel splitting [R8];

• synchronization [R9];

• exclusive choice [R10];

• simple merging [R11].

Using the eleven requirements extracted from definitions and models, we can retrieve ontology design patterns that most closely address (typically in an abstract way) the notions related to workflows.

3.1. Participation

The participation pattern17

¹⁷

http://www.ontologydesignpatterns.org/cp/owl/participation.owl.

is a simple pattern to describe processes, events, or states (in the class Event), and to specify the various objects (in the class Object) that participate in these events.

This pattern seems to be very useful to define events or actions within workflow executions, involving people, organisations, places, and other objects as participants [R5], as well as to link actions to the expected steps in a workflow [R4].

3.2. Sequence

The sequence pattern18

¹⁸

http://www.ontologydesignpatterns.org/cp/owl/sequence.owl.

is an abstract pattern that generalizes over arbitrary (spatial, temporal, conceptual, logical) sequential orderings. It can be used between tasks, processes or time intervals, in order to define sequences of such objects through direct (i.e., directlyFollows and directlyPrecedes) or transitive relations (i.e., follows and precedes), which are linked by means of the transitive reduction logical pattern (each direct relation is a subrelation of a transitive relation, e.g., directlyFollow owl:subPropertyOf follows).

For workflows, it results useful to describe the logical organisation of steps in a workflow [R1][R7], or the temporal ordering of actions or events in a workflow execution.

3.3. Control flow and plan execution

The control flow pattern19

¹⁹

http://www.ontologydesignpatterns.org/cp/owl/controlflow.owl.

is an OWL representation of some of the control flow patterns defined in the Workflow Patterns20

²⁰

The Workflow Patterns page is: http://www.workflowpatterns.com.

repository (cf. [27]). The control flow pattern imports other patterns: task execution, task role, sequence, participation.21

²¹

Similarly available from the ontologydesignpatterns.org portal.

The pattern represents either action tasks (typically event types), or control tasks (e.g., branching, concurrency, looping, cf. [R8–R11]). Their sequential ordering [R7] is represented by means of the sequence pattern. Tasks are distinct from actions, which are supposed to be executed based on the task structure: Individual: submission     Types: Action Individual: review     Types: Action Individual: submission-task     Types: ActionTask     Facts: taskex:isExecutedIn submission Individual: reviewing-task     Types: ActionTask     Facts:         taskex:isExecutedIn review ,         sequence:follows submission-taskThe control flow pattern is supposed to be composed with the basic plan22

²²

http://www.ontologydesignpatterns.org/cp/owl/basicplan.owl.

pattern, composed of the basic plan description23

²³

http://www.ontologydesignpatterns.org/cp/owl/basicplandescription.owl.

and the basic plan execution24

²⁴

http://www.ontologydesignpatterns.org/cp/owl/basicplanexecution.owl.

patterns. Basic plan reuses the foundational descriptions and situations pattern to relate task compositions (plans) and organised actions (plan executions). A comprehensive presentation is provided in [8] (the general axiomatization of plan models and execution, and control flows), in [25] (a description of the above mentioned patterns), and in [7] (an application of plan models to social ontology and norms). Since OWL semantics is open world, in order to enforce sequencing constraints on actions classified by a task, rules should be defined which provide integrity checks, cf. the error ontology below.

These patterns are needed to describe the kinds of steps (the term used here for tasks) in publishing workflows [R3, R4]. 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.

3.4. Time-indexed situation

The time-indexed situation pattern25

²⁵

http://www.ontologydesignpatterns.org/cp/owl/timeindexedsituation.owl.

allows the description of a situation – i.e., the class TimeIndexedSituation presented as 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 combines perfectly with plan execution in order to provide a temporal ordering to actions [R2] organised into a plan.

3.5. Error Ontology

The Error Ontology26

²⁶

http://www.essepuntato.it/2009/10/error.

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 [13]):

DataProperty: error:hasError   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 [R6]. For instance, we could use it to deny the specification of a certain object as input of a step if it will be produced only as output of one of the following steps.

4. PWO: The Publishing Workflow Ontology

In order to accommodate workflow requirements, we developed the Publishing Workflow Ontology27

²⁷

http://purl.org/spar/pwo.

(PWO),28

²⁸

As already introduced in Section 2, in PWO we do not directly reuse any particular entity defined in the ontologies described in Section 2 on purpose. This was due to a particular design choice during the development of PWO, i.e., we wanted to rely only on a pattern-based supported ontology development, while the alignment to existing ontologies is available in a separate file from http://purl.org/spar/pwo-alignment.

which is entirely based on the ontology patterns introduced in Section 3. This ontology enables the description of the logical steps in a workflow, as, e.g., the process of publication of a document. Each step may involve one or more events (or actions) that take place in 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.). Currently (March 14, 2016) the ontology:

• imports eight ontologies (seven of which describing existing patterns);

• defines four new classes (pwo:Workflow, pwo:WorkflowExecution, pwo:Step, pwo:Action);

• defines twelve new object properties (pwo:exe-cutes, pwo:hasStep, pwo:hasFirstStep, pwo:in-volvesAction, pwo:needs, pwo:produces, and the related inverses);

• does not introduce new data properties.

Fig. 1.

Graffoo representation [6] of the Publishing Workflow Ontology (PWO).

As shown in Fig. 1, PWO is based on two main classes pwo:Workflow and pwo:Step. pwo:Workflow represents a sequence of connected tasks (i.e., steps, by using the property pwo:hasFirstStep and pwo:hasStep, which are ordered by means of pwo:hasNextStep). pwo:Workflow is a subclass of plandesc:Plan. We can use the class pwo:WorkflowExecution to represent the aggregate of the actions (class pwo:Action) executed in the steps defined in a workflow. We can then abstract from the execution of individual steps, by saying that a certain workflow execution executes a workflow.29

²⁹

If we want to check if a workflow has been actually executed, we need to aggregate the rules that check the execution of all the individual steps from a workflow.

The formal representation of the class pwo:Workflow and the related entities is introduced as follows (in Manchester Syntax):

Class: pwo:Workflow     SubClassOf:         plandesc:Plan,         pwo:hasFirstStep some pwo:Step ObjectProperty: pwo:hasStep     SubPropertyOf: plandesc:definesTask     Domain: pwo:Workflow     Range: pwo:Step ObjectProperty: pwo:hasFirstStep     SubPropertyOf: pwo:hasStep     Range:         not (pwo:hasPreviousStep some pwo:Step) ObjectProperty: pwo:hasNextStep     SubPropertyOf: sequence:directlyPrecedes     Domain: pwo:Step     Range: pwo:Step     InverseOf: pwo:hasPreviousStep Class: WorkflowExecution SubClassOf:     tisit:TimeIndexedSituation,     planex:PlanExecution,     pwo:executes some pwo:Workflow,     pwo:involvesAction some         (pwo:Action that taskex:executesTask                 some pwo:Step) ObjectProperty: pwo:executes     SubPropertyOf:         plan:satisfies     Domain: pwo:WorkflowExecution     Range: pwo:Workflow

The other main class of PWO is pwo:Step. A step is an atomic unit of a workflow, and subclass of taskrole:Task; it is characterised by (required) temporal parameters (parameter:hasParameter) describing the expected duration (time:DurationDescription) of executed actions, and it is associated with one or more (time-indexed) executed actions by using the property taskex:isExecutedIn. A workflow step usually involves some input information, material or energy needed to complete the step (i.e., pwo:needs), and some output information, material or energy produced by that step (i.e., pwo:produces). 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. The formal representation of the class pwo:Step and its related properties is the following (in Manchester Syntax):

Table 1

A summary of the main entities of PWO which have relations to some entities introduced in the patterns used

PWO entity	Pattern entity	Description
Workflow	Plan (basic plan description, via basic plan)	The class of descriptions (cf. description and situation pattern) aggregating steps that describe a conceptual workflow structure, composed by a sequence of steps
WorkflowExecution	PlanExecution (basic plan execution, via basic plan)	The class of situations “executing a workflow”, i.e., aggregating entities pertaining to a real-life work, and complying to the sequence of steps in the corresponding workflow model
Step	Task (task role, via control flow)	The class describing specific tasks that form the workflow model, and that are executed by actions within particular time intervals
Action	Action (task execution and plan execution) TimeIndexedSituation (time-indexed situation)	The class of any (time-indexed) action with at least one agent that is participant in it and that is linked to a workflow execution by means of the property involvesAction and to a step of the related workflow description by means of the property isExecutedIn (defined in task execution)
executes	satisfies (basic plan)	The object property linking an execution of a workflow to the related workflow description
hasStep	definesTask (basic plan description)	An object property linking a workflow model to a component step
hasFirstStep	definesTask (basic plan description)	A sub-property of hasStep which identifies the starting step of a workflow
hasNextStep	directlyPrecedes (sequence)	An object property linking a step in a workflow with the step that directly follows it
hasPreviousStep	directlyFollows (sequence)	An object property linking a step in a workflow with the step that directly precedes it
needs	isDefinedIn o describes (basic plan description)	The object property linking a workflow step to anything required to undertake that step, e.g., an entity participating in an action of that step, or an entity participating in another action described (cf. the description and situation pattern) by the same workflow model (e.g., executing another step in that workflow)
produces	isExecutedIn (o hasParticipant) (task execution and participation)	The object property linking a workflow step to anything the step produces, creates or results in, e.g., an entity participating in an action of such step

Class: pwo:Step     SubClassOf:         taskrole:Task,         taskex:isExecutedIn only pwo:Action,         plandesc:isTaskDefinedIn             only pwo:Workflow,         parameter:hasParameter             exactly 1 time:DurationDescription Class: pwo:Action     SubClassOf:         planex:Action,         taskex:Action,         tisit:TimeIndexedSituation ObjectProperty: pwo:involvesAction     Domain:         pwo:WorkflowExecution     Range: pwo:Action     SubPropertyChain:         pwo:executes o         pwo:hasStep o         taskex:isExecutedIn ObjectProperty: pwo:needs     Domain: pwo:Step     Range: owl:Thing ObjectProperty: pwo:produces     Domain: pwo:Step     Range: owl:Thing

PWO has been implemented according to the aforementioned ontology patterns. As shown in Table 1,30

³⁰

In the last two rows of the table, we indicate a mapping to a property chain, though this is not allowed in OWL2 description logic fragment, which only accepts the logical pattern: <PropertyChain> SubPropertyOf <ObjectProperty>, while there we would need the inverse pattern: <ObjectProperty> SubPropertyOf <PropertyChain>.

such patterns have been used as follows:

• basic plan to describe workflows as plans, and their executions;

• time-indexed situation to describe the actions executing a step, that involve a duration and that are characterised by events and objects (among which those that are needed for or produced by steps);

• sequence to define the order, in which steps appear within a workflow;

• control flow to describe the specialisation and nature of steps at planning time;

• participation to describe events (and eventually agents involved) taking part in the actions carried out according to the steps.

Fig. 2.

A diagram describing the typical publishing workflow of a journal article – note that it does not take into account any withdrawing action by the author, nor any comment made by users on publisher’s website before/after article publication.

In addition, by means of the Error Ontology, we generate an inconsistency when the steps of a workflow are not arranged in the correct temporal order. In particular, an error is raised when a step requires (property pwo:needs) a particular object to be produced (e.g., from the property pwo:produces) as consequence of another sequent step. The following excerpt shows the implementation of this constraint in a SWRL rule [14]:

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)

It is worth mentioning that the final two properties introduced in Table 1, i.e., pwo:needs and pwo:produces, are associated to the description-level of the workflow, since they are related to the class pwo:Step. However, the particular specification of what is needed/produced by a step is not yet available when one develops a workflow description. Such specification will be provided dynamically at execution time and will depend strictly on the objects that will be really used during such execution. Basically speaking, by using PWO for modelling workflows, the statements that will be specified for a particular workflow execution will (and must) populate dynamically both the workflow execution and the related workflow description.

5. Applying PWO to the publishing and legislative domains

In the next subsections we show how to describe the process of publication of a journal article, as well as the process of codification laws of US legislation step by step. The examples apply PWO to existing data from the Semantic Web Journal31

³¹

Semantic Web Journal data: http://semantic-web-journal.com/sejp.

[15], DBPedia [17], and other SPAR ontologies, such as PSO [24], C4O [5], FaBiO and CiTO [23].

5.1. A typical publishing workflow of a journal article

From the publisher’s perspective, the first step of any workflow leading to a new journal publication starts with a formal submission of a manuscript written by someone, hereinafter the author. This action 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 different reasons (e.g., appropriateness of topic, 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) to assess the quality of the submitted manuscript. The opinions returned by the reviewers are the fundamental input that the editor uses to decide upon the fate of the manuscript during the next step, i.e., the decision phase. Finally, if the manuscript has 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 terminating 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 starts, and the author revises the paper according to reviewers’ comments and editor’s suggestions, and the workflow continues 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 [26]) we create an instance of the class pwo:Workflow as composed by a definite (we consider only the first four steps in this example) number of steps:32

³²

The full Turtle sources of this example are available in [22].

:workflow a pwo:Workflow ;   pwo:hasFirstStep :step-one ;   pwo:hasStep     :step-two ,     :step-three ,     :step-four . :step-one a pwo:Step ; # Submission step   pwo:hasNextStep :step-two . :step-two a pwo:Step ; # Reviewing step   pwo:hasNextStep :step-three ;   parameter:hasParameter [       a time:DurationDescription ;       time:weeks "5"^^xsd:decimal ] . :step-three a pwo:Step ; # Notification step   pwo:hasNextStep :step-four . :step-four a pwo:Step . # Revision step

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 [4].

5.1.1. Submission

The first step of the workflow concerns the submission of a manuscript by one of its authors, in this case Paolo Ciccarese. When executing this step, the manuscript receives the “submitted” status, and it is made available to the journal editor and the reviewers for the next step of the workflow. In order to describe all the 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)33

³³

http://purl.org/spar/pso.

[24]. PSO describes the status held by a document or another publication entity at each of the 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 below:

# Workflow execution :workflow-execution a pwo:WorkflowExecution ;   pwo:execute :workflow . # Executing step 1: Submission :workflow-execution   pwo:involvesAction :submission-action . :step-one   taskex:isExecutedIn :submission-action ;   pwo:needs swj-node:432 ;   pwo:produces :submitted-status . # The event in which one of the authors # submits the manuscript :submission-action a pwo:Action ;   dcterms:description     "Paolo Ciccarese submits the paper" ;   tisit:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2013-01-21T10:08:28"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2013-01-21T10:08:28"^^xsd:dateTime ] ;   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-21T10:08:28"^^xsd:dateTime ] .

5.1.2. Reviewing

The step regarding the reviewing phase begins with the action of the editor, Giancarlo Guizzardi in the working example, who looks for appropriate reviewers. Once reviewing requests are accepted, reviewers download the manuscript, review it, and write down their comments that are eventually 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)34

³⁴

http://purl.org/spar/c4o.

[5] the Citation Typing Ontology (CiTO)35

³⁵

http://purl.org/spar/cito.

[23], in order to express the content of reviews and to explicitly link them to the reviewed manuscript. In the following excerpt we introduce the formalisation of the second step in PWO:

# Executing step 2: Reviewing :workflow-execution pwo:involvesAction   :choosing-reviewers-action ,   :reviewing-action ,   :reviews-notification-sending-action . :step-two   taskex:isExecutedIn     :choosing-reviewers-action ,     :reviewing-action ,     :reviews-notification-sending-action ; # The review process can start only when # a manuscript has been submitted pwo:needs swj-node:432 , :submitted-status ; pwo:produces   :review-1, :review-2,   :under-review-status, :reviewed-status. :choosing-reviewers-action a pwo:Action ;   dcterms:description "The editor, Giancarlo        Guizzardi, chooses Csaba Veres and Fernando        Naufel do Amaral as reviewers of the        manuscript" ;   tisit:atTime [ a ti:TimeInterval ;     ti:hasIntervalStartDate       "2013-02-18T17:04:32"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2013-02-18T17:09:56"^^xsd:dateTime ] ;   part:hasParticipant     swj:csaba-veres ,     swj:fernando-naufel-do-amaral ,     swj:giancarlo-guizzardi ,     swj-node:432 . :reviewing-action a pwo:Action ;   dcterms:description "Reviewers review the        manuscript" ;   tisit:atTime [ a ti:TimeInterval ;     ti:hasIntervalStartDate       "2013-02-26T12:00:07"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2013-04-01T05:53:24"^^xsd:dateTime ] ;   part:hasParticipant     swj:csaba-veres ,     swj:fernando-naufel-do-amaral ,     swj-node:432 . :reviews-notification-sending-action   a pwo:Action ;   dcterms:description "The reviews are sent to the        editor" ;   tisit:atTime [ a ti:TimeInterval ;     ti:hasIntervalStartDate       "2013-03-14T11:16:34"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2013-04-01T05:53:24"^^xsd:dateTime ] ;   part:hasParticipant     swj:csaba-veres ,     swj:fernando-naufel-do-amaral ,     :review-1 ,     :review-2 ,     swj:giancarlo-guizzardi . # Review 1 by Csaba Veres :review-1 a fabio:Comment ;   frbr:realizationOf [ a fabio:Review ] ;   cito:reviews swj-node:432 ; frbr:realizer swj:        csaba-veres ;   c4o:hasContent "The paper addresses a very        practical..." . # Review 2 by Fernando Naufel do Amaral :review-2 a fabio:Comment ;   frbr:realizationOf [ a fabio:Review ] ;   cito:reviews swj-node:432 ;   frbr:realizer swj:fernando-naufel-do-amaral ;   c4o:hasContent "The paper presents the Collection         Ontology (CO)..." . # The paper has been assigned to the # under-review status for a while :under-review-status a pso:StatusInTime ;   pso:isStatusHeldBy swj-node:432 ;   pso:isAcquiredAsConsequenceOf :reviewing-action ;   pso:isLostAsConsequenceOf     :reviews-notification-sending-action ;   pso:withStatus pso:under-review ;   tvc:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2013-02-26T12:00:07"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2013-04-01T05:53:24"^^xsd:dateTime ] . # The paper status has changed in ’reviewed’ # after reviewers’ comments :reviewed-status a pso:StatusInTime ;   pso:isStatusHeldBy swj-node:432 ;   pso:isAcquiredAsConsequenceOf     :reviews-notification-sending-action ;   pso:withStatus pso:reviewed ;   tvc:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2013-04-01T05:53:24"^^xsd:dateTime ] .

5.1.3. Decision

During the third step, the editor is responsible for the fate of the paper and provides a decision for it, according to reviewers’ comments. Once the decision is formalised, a decision letter is sent by email to the corresponding author (Paolo Ciccarese in the example), and the status of the paper is changed to “minor revision”. In the following excerpt we introduce the formalisation of the third step in PWO:

# Executing step 3: Notification :workflow-execution pwo:involvesAction   :decision-action , :notification-action . :step-three   taskex:isExecutedIn     :decision-action , :notification-action ;   pwo:needs     swj-node:432 , :review-1 , :review-2 ;   pwo:produces     :minor-revision-status , :decision-letter . :decision-action a pwo:Action ;   dcterms:description "The editor decides for        acceptance or not" ;   tisit:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2013-04-01T05:53:24"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2013-06-10T17:47:53"^^xsd:dateTime ] ;   part:hasParticipant     swj:giancarlo-guizzardi ,     :review-1 , :review-2 ,     swj-node:432 . :notification-action a pwo:Action ;   dcterms:description "The editor notifies his        decision to the corresponding author (i.e.,        Paolo Ciccarese)." ;   tisit:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2013-06-10T17:47:53"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2013-06-10T17:47:53"^^xsd:dateTime ] ;   part:hasParticipant     swj:giancarlo-guizzardi ,     :decision-letter ,     :review-1 , :review-2 ,     swj:paolo-ciccarese ,     swj-node:432 . # The decision letter written by the editor :decision-letter   a fabio:Letter , fabio:Email ;   frbr:realizationOf [ a fabio:Opinion ] ;   cito:citesAsRelated swj-node:432 ;   frbr:realizer swj:giancarlo-guizzardi ;   c4o:hasContent "Dear authors, Thank you for your        interest in..." . # The minor revision status assigned to the paper     after editor’s decision :minor-revision-status a pso:StatusInTime ;   pso:isStatusHeldBy swj-node:432 ;   pso:isAcquiredAsConsequenceOf     :decision-action ;   pso:withStatus swj:minorRevision ;     tvc:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2013-06-10T17:47:53"^^xsd:dateTime ] .

5.1.4. Revision

During the fourth step, the authors work 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 the execution of this step, the main result is the creation of a new version of the paper (e.g., swj-node:506 in our example) that is submitted to the next step. In the following excerpt we introduce the formalisation of the fourth step of in PWO:

# Executing step 4: Revision :workflow-execution pwo:involvesAction   :revision-action . :step-four   taskex:isExecutedIn :revision-action ;   pwo:needs     swj-node:432 , :decision-letter ,     :review-1 , :review-2 ;   pwo:produces swj-node:506 . :revision-action a pwo:Action ;   dcterms:description     "The authors revises the paper" ;   tisit:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2013-06-10T17:47:53"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2013-07-01T05:51:30"^^xsd:dateTime ] ;   part:hasParticipant     swj-node:432 , :decision-letter ,     :review-1 , :review-2 ,     swj:silvio-peroni , swj:paolo-ciccarese .

5.1.5. Querying the dataset

In Section 1 we have claimed that the explicit description of publishing process data according to appropriate models, such as PWO, may result in increasing the transparency of the (publishing) process, and in enabling the use of such data for statistical analysis.

In order to show how to query the data introduced in the previous sections in view of the aforementioned goals, we introduce a typical scenario in the scholarly publishing domain. We are interested in understanding if the estimated time for completing a certain step in a workflow is enough for completing all the actual actions related to such step. As a subtask of this quite generic scenario, we could check whether the actual time needed by reviewers for reviewing a paper is within the time range originally estimated by the editors-in-chief of the journal.

Addressing such query by means of SPARQL over PWO-designed data is quite straightforward. For instance, the following SPARQL query returns all the steps described in the example, with their estimated duration (if specified), accompanied by the actual duration needed to address all the actions related to such step.

PREFIX ti: <http://www.ontologydesignpatterns.org/      cp/owl/timeinterval.owl#> PREFIX time: <http://www.w3.org/2006/time#> PREFIX pwo: <http://purl.org/spar/pwo/> PREFIX taskex: <http://www.ontologydesignpatterns.      org/cp/owl/taskexecution.owl#> PREFIX tisit: <http://www.ontologydesignpatterns.      org/cp/owl/timeindexedsituation.owl#> PREFIX dcterms: <http://purl.org/dc/terms/> PREFIX parameter:   <http://www.ontologydesignpatterns.org/cp/owl/parameter.owl#> SELECT ?execution ?step ?original_duration        (sum(?dur_action) as ?actual_duration) WHERE {   {     SELECT ?execution ?step            (min(?dateStart) AS ?start)            (min(?dateEnd) AS ?end)     WHERE {       ?step a pwo:Step ;         taskex:isExecutedIn ?a .       ?a tisit:atTime ?time .       ?execution a pwo:WorkflowExecution ;         pwo:involvesAction ?a .       ?time ti:hasIntervalStartDate ?dateStart ;         ti:hasIntervalEndDate ?dateEnd     } GROUP BY ?execution ?step ?time   }   OPTIONAL {     ?step parameter:hasParameter [       time:weeks ?weeks ] .     BIND (?weeks * 7 as ?original_duration)   }   BIND (day(?end - ?start) as ?dur_action) } GROUP BY ?execution ?step ?original_duration ORDER BY ?start

Fig. 3.

A diagram exemplifying the workflow of the codification of Title 41 of the United States Code. This diagram is not intended as a complete representation of any codification process of US titles, but rather as a graphical representation of the example introduced in this section.

Looking at the result of this query, it is straightforward to see that the second step (i.e., the reviewing phase) took fifteen days more than the estimated time, while the step that took most time to be executed was the third one (i.e., the decision phase).

5.2. An example of workflow in the legislative domain

Although PWO had been thought to describe workflows related with the scholarly publishing domain, it has been developed on purpose as an ontology for the description of generic publishing workflows. To this end, in this section we show how to use PWO to describe a workflow that concerns the process of codification of a particular law of the United States legislation, i.e., the codification of Title 41 of the United States Code, as described in an introductory webpage of the Office of the Law Revision Counsel.36

³⁶

Positive law codification of title 41 of the United States Code: http://uscode.house.gov/codification/t41/index.html.

A graphical summarisation of such codification process is shown in Fig. 3,37

³⁷

The full Turtle sources of this example are available in [21].

while a PWO exemplification of the workflow description is presented as follows:

# Initial workflow description :workflow a pwo:Workflow ;   pwo:hasFirstStep :step-one ;   pwo:hasStep     :step-two ,     :step-three ,     :step-four . # Introduction of the codification bill :step-one a pwo:Step ;   pwo:hasNext :step-two . # The bill was reported by the # Committee Judiciary House :step-two a pwo:Step ;   pwo:hasNext :step-three . # The bill was passed by # the House of Representatives :step-three a pwo:Step ;   pwo:hasNext :step-four . # The bill became Public Law 111-350 :step-four a pwo:Step .

5.2.1. Introduction

The first step of this workflow is the introduction of a new codification, in our example the codification bill “H.R. 1107” by Chairman Conyers and Ranking Member Smith on February 23, 2009. The result of the first step is the production of a first version of such bill. The step is rendered through PWO as follows:38

³⁸

The RDF representation of the agents involved in this and in the following examples are taken from DBpedia, where the prefix dbpedia stands for http://dbpedia.org/resource/.

# Executing step 1: Introduction :workflow-execution   pwo:involvesAction :drafting-action . :step-one   taskex:isExecutedIn :drafting-action ;   pwo:produces     :hr-1107-bill-first-version . :drafting-action a pwo:Action ;   dcterms:description "Drafting the codification        bill H.R. 1107" ;   tisit:atTime [     a ti:TimeInterval ;     ti:hasIntervalEndDate       "2009-02-23T00:00:00Z"^^xsd:dateTime ] ;   part:hasParticipant     dbpedia:John_Conyers ,     <http://dbpedia.org/resource/Adam_Smith_(          politician)> :hr-1107-bill a fabio:Work ;   frbr:realization :hr-1107-bill-first-version . :hr-1107-bill-first-version a fabio:Expression ;   frbr:realizer     dbpedia:John_Conyers ,     dbpedia:Adam_Smith_(politician) .

5.2.2. Referring

The second step of the process concerns the establishment of a Committee, in the leading example, the Committee on the Judiciary of the House of Representatives, which referred the codification bill. In particular, H.R. 1107 was ordered favourably reported by the Committee on March 18, 2009. The step is rendered through PWO as follows:

# Executing step 2: Reporting by CJS :workflow-execution pwo:involvesAction   :referring-bill-committee-judiciary-house . :step-two   taskex:isExecutedIn     :referring-bill-committee-judiciary-house ;   pwo:needs :hr-1107-bill-first-version ;   pwo:produces     :hr-1107-bill-amended ,     :hr-1107-bill-reported-by-committee-judiciary-house . :referring-bill-committee-judiciary-house   a pwo:Action ;   dcterms:description     "Referring the codification bill H.R. 1107" ;   tisit:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2009-02-23T00:00:00Z"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2009-03-18T00:00:00Z"^^xsd:dateTime ] ;   part:hasParticipant     dbpedia:          United_States_House_Committee_on_the_           Judiciary ,     :hr-1107-bill-first-version . :hr-1107-bill-amended a fabio:Expression ;   frbr:realizationOf :hr-1107-bill ;   frbr:realizer     dbpedia:          United_States_House_Committee_on_the_           Judiciary ;   frbr:revisionOf :hr-1107-bill-first-version ;   pso:holdsStatusInTime     :hr-1107-bill-reported-by-committee-judiciary-          house . :hr-1107-bill-reported-by-committee-judiciary-house   a pso:StatusInTime ;   pso:isStatusHeldBy :hr-1107-bill-amended ;   pso:withStatus :reported ;   tvc:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2009-03-18T00:00:00Z"^^xsd:dateTime ] ;   pso:isAcquiredAsConsequenceOf     :referring-bill-committee-judiciary-house . :reported a pso:Status .

5.2.3. Agreeing

The third step of the process concerns passing a codification. In the example, the bill was passed by the House of Representatives on May 6, 2009. H.R. 1107 was referred to the Senate Judiciary Committee on May 7, 2009. H.R. 1107 with amendments was passed by the Senate by unanimous consent on December 2, 2010. Then, a message on the Senate action was sent to the House of Representatives. The House of Representatives agreed to the Senate amendments on December 17, 2010. The step is rendered through PWO as follows:

# Executing step 3: Agreeing :workflow-execution pwo:involvesAction   :passing-by-hr ,   :receiving-bill ,   :referring-bill-committee-judiciary-senate ,   :sending-message-to-house-representatives . :step-three   taskex:isExecutedIn     :passing-by-hr ,     :receiving-bill ,     :referring-bill-committee-judiciary-senate ,     :sending-message-to-house-representatives ;   pwo:needs     :hr-1107-bill-amended ,     :hr-1107-status-reported-by-committee-judiciary          -house ;   pwo:produces     :hr-1107-status-passed-by-committee-judiciary-          senate ,     :message-on-senate-action ,     :hr-1107-status-agreed-by-house-representatives          . :passing-hr a pwo:Action ;   dcterms:description     "Passing the codification bill H.R. 1107 by the           House of Representatives" ;   tisit:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2009-05-06T00:00:00Z"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2010-12-17T00:00:00Z"^^xsd:dateTime ] ;   part:hasParticipant     dbpedia:United_States_House_of_Representatives          ,     :hr-1107-bill-amended . :receiving-bill a pwo:Action ;   dcterms:description "Receiving the codification        bill H.R. 1107" ;   tisit:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2009-05-06T00:00:00Z"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2010-12-17T00:00:00Z"^^xsd:dateTime ] ;   part:hasParticipant     dbpedia:United_States_Senate . :hr-1107-status-passed-by-committee-judiciary-      senate   a pso:StatusInTime ;   pso:isStatusHeldBy :hr-1107-bill-amended ;   pso:withStatus :passed ;   tvc:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2010-12-02T00:00:00Z"^^xsd:dateTime ] ;   pso:isAcquiredAsConsequenceOf     :referring-bill-committee-judiciary-senate . :referring-bill-committee-judiciary-senate   a pwo:Action ;   dcterms:description "Referring the codification        bill H.R. 1107" ;   tisit:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2009-05-06T00:00:00Z"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2010-12-17T00:00:00Z"^^xsd:dateTime ] ;   part:hasParticipant     dbpedia:          United_States_Senate_Committee_on_the_           Judiciary ,     :hr-1107-bill-amended . :hr-1107-status-agreed-by-committee-judiciary-      senate   a pso:StatusInTime ;   pso:isStatusHeldBy :hr-1107-bill-amended ;   pso:withStatus :passed ;   tvc:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2010-12-02T00:00:00Z"^^xsd:dateTime ] ;   pso:isAcquiredAsConsequenceOf     :referring-bill-committee-judiciary-senate . :sending-message-to-house-representatives a pwo:      Action ;   dcterms:description "Sending a message to the        House of Representatives about Senate action         on of H.R. 1107" ;   tisit:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2009-05-06T00:00:00Z"^^xsd:dateTime ;     ti:hasIntervalEndDate       "2010-12-17T00:00:00Z"^^xsd:dateTime ] ;   part:hasParticipant     dbpedia:United_States_House_of_Representatives          ,     :hr-1107-status-passed-by-committee-judiciary-          senate ,     :message-to-house-representatives . :message-on-senate-action   a fabio:Expression ;   frbr:realizer     dbpedia:          United_States_Senate_Committee_on_the_           Judiciary ;   frbr:realizationOf [     a frbr:Work ;     frbr:subject       :hr-1107-status-passed-by-committee-judiciary            -senate ,       :referring-bill-committee-judiciary-senate ]            . :hr-1107-status-agreed-by-house-representatives   a pso:StatusInTime ;   pso:withStatus :agreed ;   pso:isStatusHeldBy :hr-1107-bill-amended ;   tvc:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2010-12-17T00:00:00Z"^^xsd:dateTime ] ;   pso:isAcquiredAsConsequenceOf     :referring-bill-committee-judiciary-senate . :passed a pso:Status . :agreed a pso:Status .

5.2.4. Signing

In the latest step of the process the signature of the President of U.S. is required to get a codification its legal status. H.R. 1107 was signed by the President on January 4, 2011, and became Public Law 111-350, which was codified in Title 41 of the United States Code.

# Executing step 4: Signing :workflow-execution pwo:involvesAction   :hr-1107-passing-by-president . :step-four   taskex:isExecutedIn     :hr-1107-passing-by-president ;   pwo:needs     :hr-1107-bill-amended ,     :hr-1107-status-agreed-by-house-representatives          ;   pwo:produces     :hr-1107-status-signed-by-president ,     :public-law-111-350 ,     :title-41-enacted-by-public-law-111-350 . :hr-1107-passing-by-president a pwo:Action ;   dcterms:description "Passing the codification        bill H.R. 1107 by the President for signing        it" ;   tisit:atTime [ a ti:TimeInterval ;     ti:hasIntervalStartDate       "2010-12-17T00:00:00Z"^^xsd:dateTime ;     ti:hasIntervalEndDate      "2011-01-04T00:00:00Z"^^xsd:dateTime ] ;   part:hasParticipant     dbpedia:President_of_the_United_States ,     :hr-1107-bill-amended . :hr-1107-status-signed-by-president   a pso:StatusInTime ;   pso:isStatusHeldBy :hr-1107-bill-amended ;   pso:withStatus :signed ;   tvc:atTime [     a ti:TimeInterval ;     ti:hasIntervalStartDate       "2010-12-17T00:00:00Z"^^xsd:dateTime ] ;   pso:isAcquiredAsConsequenceOf     :hr-1107-passing-by-president . :public-law-111-350 a fabio:Work ;   frbr:adaptationOf :hr-1107-bill-amended ;   frbr:realization [ a fabio:Expression ;     cito:providesExcerptFor       :title-41-enacted-by-public-law-111-350 ] . :title-41 a fabio:Work ;   frbr:realization     :title-41-negative-law ,     :title-41-enacted-by-public-law-111-350 . :title-41-enacted-by-public-law-111-350   a fabio:Expression ;   frbr:revisionOf :title-41-negative-law . :signed a pso:Status .

6. Conclusion

In this paper we introduced the Publishing Workflow Ontology (PWO), i.e., an OWL 2 DL ontology that is part of the Semantic Publishing and Referencing (SPAR) Ontologies [20]. PWO enables the description of publishing workflows in RDF. The whole ontology is entirely founded on existing ontology design patterns that allow us to satisfy the identified requirements by reusing best practices. We have shown two applications of PWO: describing a real publishing workflow for the publication of an article [4] in the Semantic Web Journal, and the process of codification of laws within U.S. legislation – in which we have reused entities and data from existing resources such as the Semantic Web Journal Linked Dataset.

Although PWO was designed for modelling publishing-related workflows, it can be easily reused of generic workflows, since it stands on top of abstract, off-the-shelf ontology design patterns. PWO is aligned to other workflow-related models, e.g., PROV-O, the Research Object ontology and the ontologies described in Section 2. In addition, we are studying the applicability of PWO to other domains, e.g., for describing workflows of computational or data manipulation in scientific applications. Finally, we also plan to develop some APIs in order to facilitate the adoption of PWO within existing publishing platforms.