Keywords

1 Introduction

Traditionally, business processes have been modeled as workflows of activities. The primary disadvantage of such approach is the separation between data models and process aspects of businesses [5]. An alternative and more recent approach is the artifact-centric process modeling approach [14], which combines both data and their manipulation into cohesive and modular units known as business artifacts or artifact types in a broad sense. The artifact-centric approach demonstrates many advantages and benefits including; enabling a natural modularity and componentization of business processes, facilitating business transformations and organizational changes and providing a framework of varying levels of abstraction to develop business processes to name a few [5, 8]. On the other hand, being complex entities, artifacts require suitable methods and technologies in order to be implemented and treated efficiently. Nonetheless, artifacts have attracted much attention from the research communities. Few initiatives attempt to manage them recently as graphical-based models (i.e. Artiflow) or as data objects using relational databases (SQL) or data-centric dynamic system (DCDS) [7, 16]. Since artifacts are complex models, including attribute-value pairs information model, state-based lifecycles, and transitions that invoke services to move artifacts from a current state to a new state of their lifecycle. These initiatives show their limits and do not allow end-users to benefit from the full potential and flexibility that artifacts can provide. In fact, graphical-based models often focus on defining and running artifact processes. They are thus not convenient for querying artifacts. However, using relational databases to manage artifact structures require nested and tedious queries taking into account table relationships, constraints, dependencies and their keys. As a result, a declarative and expressive artifact language becomes essential to efficiently manage artifact types. Such language opens an era for using artifacts beyond business processes and builds new class of applications in various domains. For example, artifact types can represent connected devices or urban entities in the context of smart cities.

An artifact specific language should be compatible with the artifact model. Firstly, it should consider that an artifact, as a cohesive entity, could be created, updated or dropped as the need arises. Moreover, artifacts have to interact with each other through events in order to exchange necessary information and update their lifecycles. Secondly, artifacts must evolve in a state-based lifecycle starting at an initial state, passing in intermediate states, and ending in one of their final states. As a result, an artifact specific language should not only meet all these requirements and challenges but it should also be simple enough in order to be used by non-IT specialists within and beyond business processes.

In this paper, we propose the Artifact Query Language (AQL) that is specifically designed to take full advantage of the artifact model. The AQL is a high-level declarative language that deals with defining and manipulating artifacts at the business logic level. It is based-on the SQL and extends it with artifact domain specific statements. The AQL relieve users from dealing with multiple tables, primary and foreign keys constraints, and constructing complex SQL queries that include joins and nested sub-queries. As a result, The AQL is intended to be used by non-IT specialists and enables them to write queries that focus on the artifact logic instead of dealing with technical details related to SQL and artifact complex structure management. Moreover, the AQL can co-exist with graphical based artifact systems such as Artiflow [16]. The proposed AQL is an abstraction layer over SQL and translates all its queries into underlying SQL queries. The semantics of the AQL is thus expressed in terms of the relational model.

The remaining of the paper is organized as follows. Section 2 describes the syntax of AQL and provides query examples. Section 3 presents the semantics of AQL expressed in terms of the relational model whereas Sect. 4 illustrates the prototype implementation. Related works and similar initiatives are discussed in Sect. 5. Finally, Sect. 6 concludes the work and provides future perspectives.

2 Syntax

The Artifact Query Language (AQL) is a high-level language that is based-on the relational database SQL. Since it is an abstraction layer over SQL, it follows the syntax of SQL statements, with some variations, but provides a simplified syntax that is translated into SQL queries. The AQL consists of the Artifact Definition Language (ADL) to define artifact classes, and the Artifact Manipulation Language (AML) to manage artifact instances.

Thus, ADL includes a statement to define artifact classes. For example, the Create Artifact statement allows the definition of a list of simple and complex data attributes, references to child artifact classes, and a list of states, representing stages of artifact lifecycles [4]. As for the AML, it includes statements to instantiate, manipulate and interrogate artifact instances. For example, the New statement instantiates new artifact instances; the Update statement updates simple attribute types and states; the Insert Into and Remove From statements are used to insert and remove (business) objects (complex attributes values) and child artifacts (reference attributes values) respectively into and from artifacts; the Delete statement deletes artifact instances altogether from the database; the Retrieve statement retrieves artifact instances that meet conditions.

In the following sections, we first describe a scenario to illustrate the AQL with query examples for each of its statements. We secondly introduce in details the syntax of ADL and AML statements.

2.1 Example Scenario

In order to illustrate the AQL queries through a scenario, we define business processes related to the candidate admission application in an academic program. In this scenario, the business process in a university begins with the candidate submitting his application to the secretary of the Master program. The secretary creates a new application file to process the candidature and records personnel information such as; first name, last name and age. The secretary then collects and scans required documents including a CV, diplomas, and motivation letters. If all required documents are presented, the secretary marks the application as complete, otherwise the application is marked as incomplete and is rejected. After that, the master program chair inspects all complete applications and checks if they are eligible. If an application is not eligible, the candidature is rejected; otherwise the candidate is selected to be interviewed by academic committee members on a specified date and location. During the interview, notes and decisions about the candidate are taken by the committee members. If needed, additional interviews can also be scheduled for the same candidate. Finally, interviews are evaluated and decisions are made about whether candidates are accepted or rejected.

We identify two artifacts in the candidate admission process; (1) The Candidate Application Artifact (CAA), which deals with processing candidate applications and tracks various decisions made about them, and (2) The Candidate Interview Artifact (CIA), which deals with interviewing candidates, collecting and evaluating interviews’ information. In the following sections, we rely on these artifacts to formulate query examples.

2.2 Artifact Definition Language

The Artifact Definition Language (ADL) is used to define an artifact class or artifact type with respect to the artifact model. It consists of a list of data attributes and a list of states. Data attributes can be of three types: simple type, complex type, and reference type.

  1. 1.

    The simple attribute types represent simple types such as Boolean, Integer, Real or String. Simple attribute can only store one value at a time. For example the FirstName attribute type in the Candidate Application Artifact may have the string value “John.”

  2. 2.

    The complex attribute types represent complex structures that are made up of one or more simple attribute types. These complex structures describe the (business) objects that can be inserted and/or removed from artifacts. For example, the Documents complex attribute type in the Candidate Application Artifact is formed from a tuple of three simple attribute types: Type, Title, and URL. Complex attribute types have a cardinality of one or many. For example, several Documents can be inserted into the Candidate Application Artifact.

  3. 3.

    The reference attribute types in a master artifact represent references to child artifacts related to the master artifact. Reference attribute types have a cardinality of one or many. In other words, a reference type attribute can store a list of references to several artifact instances. For example, an Interviews reference attribute type in the Candidate Application Artifact refers to the Candidate Interview Artifact and thus, may have a list of one or more references to Candidate Interview Artifact instances.

  4. 4.

    In addition, the list of states in the artifact class describes possible stages of the artifact’s lifecycle. These states include initial, final, or intermediate states. An artifact instance can only be in one state of its lifecycle at a time. For example, the Candidate Interview Artifact instance may have the accepted state during its processing.

The Create Artifact statement is illustrated in Fig. 1(a) and shows the example of defining the Candidate Application Artifact (CAA). ApplicationArtifactId, FirstName, LastName and Age are simple attribute types. Documents is a complex attribute type. Whereas Interviews is a reference attribute type pointing to the Candidate Interview Artifact (CIA). Initialized, Created, Rejected, Complete, Interviewed, and Accepted denote states of its artifact lifecycle in which Initialized is the initial state, Rejected and Accepted are two final states, and remaining states are intermediate states. Figure 1(b) illustrates the grammar of the Create Artifact Statement.

Fig. 1.
figure 1

Create artifact statement

Full size image

2.3 Artifact Manipulation Language

The Artifact Manipulation Language (AML) consists of six statements to instantiate, modify and retrieve artifact instances.

2.3.1 Instantiate Statement

Since artifacts denote complex data structures that are composed of simple, complex and reference attribute types and a list of states, several tuples must be inserted into two or more tables in the underlying relational database when creating new artifact instances. The traditional SQL’s INSERT statement is thus not sufficient to create several tuples. Hence, the New statement instantiate a new artifact instance and initializes its attributes values and state.

The New statement exhibits several modes of uses. The first mode creates a new artifact instance and initializes some of its simple attributes as illustrated in Fig. 2(1) where a Candidate Application Artifact instance is created with 100543 as the value of its ApplicationArtifactId attribute. Additionally, its state is automatically initialized to its initial state “initialized” as defined in the Create Artifact query in Fig. 1.

Fig. 2.
figure 2

New query examples

Full size image

In order to initialize the artifact to a particular state, the “Set State To StateName” clause must be used as illustrated in Fig. 2(2) where in addition to initializing the ApplicationArtifactId, FirstName, LastName and Age, the state is initialized to “Created”. The New statement can also be used to initialize complex attributes as illustrated in in Fig. 2(3) where three documents including a CV, a diploma, and a recommendation letter are inserted into the new Candidate Application Artifact instance. Finally, the New statement can be used to initialize reference attributes as illustrated in Fig. 2(4) where two references to Candidate Interview Artifact instances with InterviewArtifactId respectively equal to 205465 and 206721 are inserted into the new CandidateApplicationArtifact instance. Figure 3 illustrates the grammar of the New statement.

Fig. 3.
figure 3

New statement grammar

Full size image

2.3.2 Modification Statements

Modification of artifact instances can be performed at several levels: (1) update simple attribute values, (2) update states, (3) update tuples of complex attributes, (4) insert or remove tuples of complex attributes, (5) insert or remove references to child artifacts, and finally (6) delete artifact instances.

First, simple attribute values of artifact instances can be updated as in SQL using the Update statement as illustrated in Fig. 4(1). Similarly, the states of artifact instances can be updated using the Update statement as illustrated in Fig. 4(2).

Fig. 4.
figure 4

Modification query examples

Full size image

In this case, the “Set State To StateName” clause is used to specify the new state. Finally, modifications of tuples of complex attributes are also performed using the Update statement expressed with the “ Update AttributeName In ArtifactName” clause to indicate in which artifact the complex attribute is located. Figure 4(3) illustrates an example where the Type attribute of the document with the title “Bachelor in CS” in the Candidate Application Artifact instance (id 100543) is updated with the value “Certificate”.

Inserting tuples of complex attributes into artifact instances can be performed using the “ Insert AttributeName Into ArtifactName” clause to indicate in which artifact the complex attribute is located and specifying a list of tuples to be inserted (see Fig. 4(4)). Similarly, inserting a reference into a child artifact in a given artifact can be performed using the Insert Into statement (Fig. 4(5)). In this case the child artifact instance is selected using the condition specified in the “ Where Condition” clause. Removing complex attribute tuples and child artifact references from artifact instances can be performed using the Remove From statement as illustrated in Fig. 4(6) and 4(7). The Remove From statement functions in the same way as the Insert Into statement. Finally, deletion of artifact instances can be performed using the Delete statement as illustrated in Fig. 4(8). In this case, the artifact instance including its complex attributes tuples and child artifact references are deleted. Figure 5 illustrates the grammar of modification statements where the production rules for the WHERECLAUSE are omitted and listed instead in Fig. 7 for readability concerns.

Fig. 5.
figure 5

Modification statements grammar

Full size image

2.3.3 Retrieve Statement

Artifact instances and their content can be retrieved using the Retrieve statement, which is an abstraction statement over SQL’s SELECT statement. Retrieving artifact instances according to the values of their simple attributes and state is performed as illustrated in Fig. 6(1). All information related to the artifact instance including the values of its simple attributes, state, tuples of its complex attributes, and artifact instances of its reference attributes are retrieved by default. The “ Only ” keyword restricts the retrieval of values to simple attributes and states of the master artifact (see Fig. 6(2)). Retrieving artifact instances according to the values of their complex attributes is performed using the “ Include ” operator as illustrated in Fig. 6(3). The asterisk symbol (*) is used to match any string of characters. In this case, the retrieved artifact instances should have two documents with the Title respectively equal to “Bachelor in Computer Science” and “Recommendation Letter from Professor”. Retrieving artifact instances according to their child artifacts is performed as illustrated in Fig. 6(4). In this case, the “ Having ” operator is used to specify the condition that the child artifacts should meet. Finally, retrieving only the values of complex or reference attributes can be achieved using the “ Retrieve AttributeName From ArtifactName” clause (see Fig. 6(5) and (6)).

Fig. 6.
figure 6

Retrieve query examples

Full size image

Figure 7 illustrates the grammar of the Retrieve statement.

Fig. 7.
figure 7

Retrieve statement grammar

Full size image

3 AQL Semantics

This section defines the semantics of AQL in terms of the Relational Model. Firstly we formalize the notion of an artifact class based on [4] and secondly we describe every AQL statement with its operational semantics using relational model concepts as described in [2].

We start by assuming the existence of the following pairwise disjoint countably infinite sets: \( {\mathcal{D}} \) for constants; i.e. data values. \( {\mathcal{C}} \) of artifact names. \( {\mathcal{A}} \) of attribute names. STS of artifact states. \( {\mathcal{T}}_{{\text{prim}}} \) of primitive types, including Boolean, Integer, Real or String. \( {\mathcal{T}}_{{\text{com}}} \) of complex types, where elements of \( {\mathcal{T}}_{{\text{com}}} \) are subsets of \( {\mathcal{A}} \), and \( {\mathcal{T}} \) of types, where \( {\mathcal{T}} = {\mathcal{T}}_{{\text{prim}}} \cup {\mathcal{T}}_{{\text{com}}} \cup \;{\mathcal{C}} \).

We also give some simple notations for relations and relation schemas. For a given relation schema R, we denote by schema(R) ⊆ \( {\mathcal{A}} \) the set of attributes in R. The primary key of R is denoted by key(R) ⊆ schema(R). A tuple t over R is an element of \( {\mathcal{D}}^{{\left| {schema\left( R \right)} \right|}} \), and a relation r over R is a finite set of tuples over R such that r ⊆ D |schema(R)|. We also assume the existence of a relation states over a relation schema States used to store information about states of lifecycles with schema(States) = {Artifact, State, Type} and key(States) = {Artifact, State}.

We also make use of the following relational algebra operators; selection, projection, cartesian product and assignment. Selection is denoted by σ c (r) where a subset of tuples that meet condition c is selected from the relation r. Projection is denoted by π a1,…,an (r) where the result is a relation of n attributes obtained by erasing from the relation r the attributes that are not listed in a 1 ,…,a n . Cartesian product is denoted by r 1  × r 2 where the result is a relation that combines r 1 and r 2 . Relational algebra expressions can be constructed using selection, projection and Cartesian product operators in addition to mathematical union and set difference operators. Assignment is denoted by r ← E where the result of the relational algebra expression E is assigned to the relation r. Using the assignment operator, we can define insert, delete and update operations on relations. Inserting a tuple t into a relation r is defined as r ← r ∪ t. Deleting a tuple t from a relation r is defined as r ← r − t. Updating a tuple t in a relation r is defined as r ← r – t ∪ t′ where t′ is the updated tuple.

3.1 Artifact Definition Language

The Create Artifact statement of ADL is used to define artifact classes according to the structure defined in Definition 1.

Definition 1 (Artifact Class).

An Artifact Class C is a tuple (C, A, τ, Q, s, F) where C ∈ C is a class name, A ⊆ \( {\mathcal{A}} \) is a finite set of attributes, τ: A → \( {\mathcal{T}} \) is a total mapping, Q ⊆ STS is a finite set of states, and s ∈ Q, F ⊆ Q are respectively initial and final states.

Taking as an example the Create Candidate Application Artifact query of Fig. 1, we would have: C = CAA, A = {ApplicationArtifactId, FirstName, LastName, Age, Documents, Interviews}, τ(ApplicationArtifactId) = Integer, τ(FirstName) = String, τ(LastName) = String, τ(Age) = Integer, τ(Documents) = {Type, Title, URL} where τ(Type) = String, τ(Title) = String and τ(URL) = String, τ(Interviews) = CIA, Q = {Initialized, Created, Rejected, Complete, AwaitingInterview, Interviewed, Accepted}, s = Initialized, and finally, F = {Rejected, Accepted}.

The defined artifact is implemented in the relational model according to the following semantics:

First, a relation schema C r that represents the artifact class C is created. C r will contain the simple attributes of C such that schema(C r ) = {a | a ∈ A and τ(a) ∈ \( {\mathcal{T}}_{{\text{prim}}} \)}. In addition to two more attributes: a pk  = concat(C, “_PK”) is the primary key of C r such that key(C r ) = a pk , and a st  = State is the current state of the artifact. In our example, we obtain the relation schema CAA( CAA_PK , ApplicationArtifactId, FirstName, LastName, Age, State).

Second, for every complex attribute a com such that a com ∈ A and τ(a com ) ∈ \( {\mathcal{T}}_{{\text{com}}} \), we create an associated relation schema A r containing the simple attributes constituting a com such that schema(A r ) = {a | a ∈ τ(a com ) and τ(a) ∈ \( {\mathcal{T}}_{{\text{prim}}} \)}. Additionally, schema(A r ) will contain a primary key attribute a pk such that key(A r ) = a pk and a pk  = concat(a com, “_PK”). Moreover, schema(A r ) will also contain a reference to the artifact in the form of a foreign key a fk of C r such that a fk  = concat(C r , “_FK”). In our example, we obtain the relation schema Documents( Documents_PK , CAA_FK, Type, Title, URL).

Third, for every reference attribute a ref of C such that a ref ∈ A and τ(a ref ) ∈ C, we create an associated relation schema A r that contains the foreign keys of the parent and child artifacts such that schema(A r ) = {a parent , a child | a parent  = concat(C, “_PFK”) and a child  = concat(τ(a ref ), “_CFK”)}. Additionally, both foreign keys will form the primary key of A r such that key(A r ) = {a parent , a child }. In our example, we obtain the relation schema Interviews(CAA_PFK, CIA_CFK) which is used to store many-to-many references between Candidate Application Artifacts and Candidate Interview Artifacts.

Finally, for every state q of C, we insert a tuple t into the relation states such that; 1) states ← states ∪ {(C, q, “default”)} if q ∈ Q and q ≠ s and q ∉ F. 2) states ← states ∪ {(C, q, “initial”)} if q ∈ Q and q = s. 3) states ← states ∪ {(C, q, “final”)} if q ∈ Q and q ∈ F.

3.2 Artifact Manipulation Language

We now describe the semantics of AML.

  1. (1)

    The new statement instantiate artifact instances by inserting necessary tuples into the different relations constituting the artifact. The first insert operation inserts a tuple with values of simple attributes and artifact state into the corresponding artifact relation: artifact ← artifact ∪ {(k parent , v 1 ,…, v n , state)} where k parent is the primary key of the artifact. If the state is not specified in the query, the initial state of the artifact is retrieved and used from the states relation using the expression: πState(σArtifact=artifactname ∧Type=‘initial’(states)). Similarly, if the state is specified in the query, it is validated using the expression: σArtifact=artifactname ∧State=statename (states). Then, for every complex attribute tuple, an insert operation is performed on the corresponding complex attribute relation: att complex  ← att complex ∪ {(k att , k parent , v 1 ,…,v n )} where k att is the primary key of the inserted tuple and k parent is the foreign key of the parent artifact. Similarly, for every reference attribute value, an insert operation is performed on the corresponding reference attribute relation: att reference  ← att reference ∪ {(k parent , k child )}. In this case, k parent is the foreign key of the parent artifact and k child is the foreign key of the child artifact. k child is retrieved according to the specified condition using the expression: πArtifact_PK(σcondition(artifact)).

  2. (2)

    The update statement updates simple attributes of artifacts and complex attributes, in addition to the states of artifacts. First, updating simple attributes and states of artifacts is performed by retrieving the required tuple from the artifact relation using a selection operation: t ← σ condition (artifact) where condition is the condition specified in the query. Then, an update operation is performed on the artifact relation: artifact ← artifact – t ∪ t′ where t′ is the updated tuple. On the other hand, updating complex attributes requires a Cartesian product operation in order to retrieve the correct tuple from the complex attribute relation: t ← πschema(attcomplex)(σ condition∧Artifact_PK=Artifact_FK(artifact × att complex ). Then, an update operation can be performed on the complex attribute relation: att complex  ← att complex – t ∪ t′ where t′ is the updated tuple.

  3. (3)

    The insert statement inserts tuples into complex or reference attributes relations. First, inserting a tuple (v 1 ,…,v n ) into a complex attribute is performed by retrieving the primary key of the correct artifact using a projection and selection operations: k parent  ← πArtifact_PK(σ condition(artifact)). Then, an insert operation is performed on the complex attribute relation as follow: att complex  ← att complex ∪ {(k att , k parent , v 1 ,…,v n )}. Similarly, inserting a tuple into a reference attribute is performed by retrieving both primary keys of the parent and child artifacts using projection and selection operations: k parent  ← πArtifact_PK(σ cparent(artifact)) where cparent is the condition related to the parent artifact. And k child  ← πArtifact_PK(σ cchild(artifact)) where cchild is the condition related to the child artifact. Then, an insert operation is performed on the reference attribute relation as follow: att reference  ← att reference ∪ {(k parent , k child )}.

  4. (4)

    The remove statement deletes tuples from complex or reference attribute relations. Removing a tuple t from a complex attribute relation is performed similarly to the update statement for complex attributes. But, a delete operation is used instead of an update operation: att complex  ← att complex  − t. On the other hand, removing a tuple from a reference attribute relation is performed similarly to the insert statement for reference attributes. But, a delete operation is used instead of an insert operation: att reference  ← att reference  − {(k parent , k child )}.

  5. (5)

    The delete statement deletes tuples from artifact relations, in addition to all related tuples from complex and reference attribute relations. First, all tuples from all complex and reference attribute relations are deleted as described in the remove statement. Then similarly, the tuple corresponding to the artifact is deleted from the artifact relation.

  6. (6)

    The retrieve statement selects tuples that meet certain conditions from artifact relations, in addition to related tuples from complex and child artifact relations. First, tuples from the artifact relation that meet the condition on simple attributes and state of the artifact are selected using: r 1  ← σ cparent(artifact) where c parent is the condition related to the simple attributes and state of the artifact. Second, for conditions on the complex attributes of the artifact, expressed using the “include” keyword, further selections are performed on the Cartesian product of r 1 and the related complex attribute relation att Complex such as: σ ccomplex∧Artifact_PK=Artifact_FK(r 1  × att Complex ) where att Complex is the complex attribute relation, and c complex is the condition related to the complex attribute. Similarly, for conditions on the reference attributes of the artifact, expressed using the “having” keyword, a selection is performed on the Cartesian product of r 1 , the reference attribute relation att reference , and the artifact relation artifact: σ cchild∧ r1.Artifact_PK=Artifact_PFK∧Artifact_CFK=artifact.Artifact_PK(r 1  × att reference  × artifact).

4 Implementation

Using the semantics described in Sect. 3, we have implemented a compiler that translates AQL into SQL. The compiler relies on the AQL grammar described in Sect. 2 and an extended attribute grammar that uses synthesized and inherited attributes to generate SQL queries from AQL queries. Figure 8 illustrates an example of an AQL production rule where AttName, AttType, AList, RefAtt, MetaType, Sal and Sql are synthesized attributes and ArtName is an inherited attribute. In this production rule several cases exist. (1) If the data attribute has simple type MetaType(ATTRIBUTETYPE) == “simple”, then it is appended to a list of simple type data attributes Sal(ATTRIBUTE). (2) If the data attribute has complex type MetaType(AttributeType) == “complex”, then its CREATE TABLE SQL query is generated and assigned to Sql(ATTRIBUTE). (3) Similarly, if the data attribute has reference type MetaType(AttributeType) == “reference”, then its CREATE TABLE SQL query is generated and assigned to Sql(ATTRIBUTE).

Fig. 8.
figure 8

Attribute grammar example

Full size image

The compiler relies on the Java Xtext framework to develop our domain-specific language and conduct lexical and syntax analysis and code generation. It connects to a MySQL server as a back-end database. The compiler interface translates queries written in AQL into SQL and then executes them.

5 Related Works

Artifacts have gained a lot of attention from a theoretical perspective to formally defining artifacts and studying their properties. Many works have tackled challenges related to lifecycle modeling, conformance, validation, verification, operational semantics and synthesis problems [4, 5, 8]. However, there is still a lot of room for developing artifact-based management systems. The SQL for Business Artifacts (BASQL) introduced in [10] was a first attempt to describe SQL-like statements to define and manipulate artifacts. BASQL still treats business artifacts as traditional relations made of simple type attributes, and as such, instances are manipulated and interrogated using normal SQL statements, operating on relations. On the other hand, many works have focused on defining syntactical and graphical languages to define artifact processes. Works in [13] have introduced the Business Entities and Business Entity Definition Language (BEDL). The BEDL is an XML-based language that specifies business artifact process models, including, Business Entities (or Artifacts), Lifecycles, Access Policies, and Notifications. The BEDL only deals with defining business artifact processes and does not introduce statements to manipulating or interrogating business artifact instances. Business artifact processes are also defined using Active XML (AXML) [1, 3]. A business artifact instance is written as an XML document with embedded function calls. The business artifact process is thus executed by invoking embedded functions and assigning their results to business artifact attributes. The AXML artifact model is concerned with defining and executing the artifact process and does not deal with manipulating and interrogating business artifact instances. Several graphical languages and notations have been developed to define business artifact processes. Authors in [12, 14] introduce a graphical notation to model business artifact lifecycles as finite-state machines. This graphical notation is based on three modeling constructs: Task, Repository, and Flow Connectors. A similar notation is introduced in [11] where the artifact-centric model is called Artifact Conceptual Flow or ArtiFlow (named EZ-Flow in [15]). On the other hand, business artifact lifecycles are declaratively modeled using the Guard-Stage-Milestone (GSM) notations [6, 9]. By using Guards, Stages and Milestones as modeling primitives, the GSM notation allows parallelism and hierarchies in business artifact lifecycles. Roughly speaking, graphical languages and notations focus on defining and executing business artifact processes but they do not include statements to specifically manage business artifact instances. To the best of our knowledge, no work, prior to this work, has focused on defining a declarative language that specifically manipulates and interrogates artifacts with focus on the artifact model regardless its underlying data and structure.

6 Conclusion

Artifacts, as a process modeling approach, advocate the unification of data and processes and offer many advantages to their users. Despite recent advances in the field of artifacts, defining, manipulating and interrogating artifacts are still in their infancy. In this paper, we presented the Artifact Query Language (AQL) that seeks to define, manipulate, and interrogate artifacts with declarative SQL-like statements. Future works include the addition of statements to create business rules and services in AQL and the automatic generation of services’ method stubs in a procedural programming language. In order to support Artifact streams, we are seeking to extend the AQL with continuous querying capabilities with sliding windows and apply them to high throughput real-time streams in the context of smart cities.