The Common Statistical Production Architecture (CSPA) is a reference architecture for the statistical industry. In particular, CSPA aims at documenting statistical services in a standard way, in order to ease their exchange and reuse between statistical institutes. This paper describes a suggested formalization of some parts of the CSPA speci cation using OWL. This work led to propose some adjustments that could improve the consistency and clarity of the speci cation.
1.1
Since 2010, the United Nations Economic Commission for Europe (UNECE)
leads an global e ort to develop common standards and models and to foster
cooperation in the o cial statistics community. The agship of this e ort is
the Common Statistical Production Architecture (CSPA) [
CSPA comprises in particular: conceptual data and process models1, a logical information model (LIM), standard templates for documenting statistical services, standard roles for conceiving, developing and implementing those services, architectural principles at the application and technology levels, etc.
This di erent components do not exhibit the same level of formalization. The
information models are expressed as UML, and work has already been conducted
to represent the generic process model using OWL [
To address these problems, a more formal representation of some parts of the CSPA speci cation is needed. This is what we are aiming at in this paper. ?? Institut National de la Statistique et des Etudes Economiques, http://insee.fr
Statistical+Information+Model) and GSBPM (http://www1.unece.org/stat/ platform/display/metis/The+Generic+Statistical+Business+Process+Model).
We want to formalize the CSPA speci cation using OWL [
We should note that applying formalism on existing material can raise difculties. Sometimes, adaptations to the CSPA concepts or vocabularies would ease the process. Even if our main goal is not change to CSPA speci cation but to foster its use within the statistical community, we had to suggest some changes and leave open some questions. This will be reported back to the CSPA management team. 1.3
The goal of CSPA is not unique. On the one hand it is a representation of
processes, on the other hand it is a way to share IT components between statistical
institutes. This duality obliges us to be cautious: if the ontology is too
conceptual, few people will use it; if it is not conceptual enough, it will not allow e cient
exchange of information. In order to evaluate the right level of representation,
we rst studied the CSPA descriptions already provided by several institutions
[
We decribe in this section the di erent notions de ned by the CSPA speci cation, in order to prepare the development of the ontology, which will be described in the next section.
CSPA distinguishes between three levels of service description, and associates
prede ned organisation roles to them:
Service de nition (SD) is the conceptual level which is human-oriented and
has less details. It is the user's view, independent of physical implementation.
It is made by a Service Designer, using conceptual models like the GSIM [
Service speci cation (SS) is the logical level. It ensures that the service description meets the requirements of CSPA. It is made by the Service Designer, using logical models like the CSPA LIM or the information models associated with DDI3 or SDMX4.
computer oriented and has most details. It is made by a Service Builder or Service Assembler, using (among others) DDI or SDMX instances. 2.3
We can see from existing examples that current implementers of CSPA want to specify two slightly di erent things, namely packages and functions. One service may actually be a bundle of functions, potentially accessible via di erent protocols. Thus we need to describe not only the bundle of functions as one entity but also each and every function in the bundle. Depending on the context, the bundle can also be seen as an independant software or only a package. To help our analysis, we studied di erent package description systems, in particular: JavaDoc5, Debian Control File6 (also used by R) and Python7. As a result, we introduced a distinction between functions and packages, even if the current CSPA speci cation does not make this distinction clearly. We split the 3 levels of CSPA into 2 parts: one for functions and one for packages, as is explained further below. 2.4
We rst look at the original CSPA structure with 3 levels (cf Fig. 1), where one service de nition points to one service speci cation which points to one or more service implementation descriptions.
Then we introduce the distinction between function and package. In Fig. 2, the 3 levels of description are encapsulated inside package or function containers; one package container points to several function containers.
Conceptual level
Service De nition Logical level
Service Speci cation
SD SS Implementation level
Service Implementation Description
SID
SID
SID
This is a very theoretic representation, because in a typical situation, not every level exist for each function or package. Those missing levels (service speci cation for the CSPA package, for instance) lead to a di culty: the initial schema imposes sequential links (service de nition linked to service speci cation linked to service implementation description). That is why we must adopt a slightly di erent structure (which is exempli ed in Fig. 3), where each level inside a container is linked to the container itself and not to another level.
Package
SD
SS SID
SID Function
Function
Function SD SS
SD
SS SID
SID
SID
SID
SID
SS
The CSPA speci cation de nes di erent properties for the services, many unique to one level of description. To ease understanding, we group those properties into 8 di erent topics: Business function (only at conceptual level, mostly for packages) to describe what the service is for.
Documentation to document the service (how to use it for instance). Provenance to describe where the service and its description come from. Interface (mainly for packages) to describe how to invoke the service, for instance using Bash or a REST API Dependencies (mainly for packages) to detail what is needed to invoke the service, for instance a speci c operating system or database; this can be linked to an Interface at implementation level.
Input (only for functions) to describe the inputs of a function. Output (only for functions) to describe the outputs of a function. Identi cation (Name and Version), to identify a service unambiguously.
We list below the initial properties contained in the CSPA speci cation,
organized according to the topics that we introduced previously. At the beginning
of the line is the name of the properties topic described earlier; the names of the
initial properties follow. The full initial templates of CSPA with de nitions are
available on the UNECE website [
Business function Business Function, GSBPM, Outcomes, Restrictions Dependency Service dependencies Input GSIM Input Output GSIM Output
Interface Protocol for Invoking the Service Input Input Message Output Output Message Documentation Applicable Methodologies
Interface Invocation protocols, Service Interface Input Data-by-Reference protocols Documentation Additional information, Installation documentation Provenance Builder Organization Dependency Technical dependencies Most of those topics are often present in each of the 3 levels (de nition, speci cation, implementation).
As already mentioned, CSPA de nes [
At this stage, we have distinguished in CSPA three main semantic axes related to the statistical services: level of description, service granularity and property topics. Consequently, we will organize the global structure of the ontology with 3 levels of description (service de nition, service speci cation and service implementation description), 2 granularity categories (functions and packages), and 8 topics (Business function, Documentation, Provenance, Interface, Dependency, Input, Ouput, Identi cation).
We have also identi ed additional concepts present in the speci cation, like organizational roles.
In this section, we decribe how these di erent notions are formalized in the CSPA ontology that we propose. Due to space constraints, we limit ourselves to a narrative description: the actual code of the ontology, as well as an illustrative example on one of the existing CSPA services, can be found on GitHub8. 3.2
In order to describe granularity categories, we create two classes: Package and Function, and they are de ned as subclasses of a common PackageOrFunction class. Similarly, ServiceDe nition, ServiceSpeci cation and ServiceImplementationDescription classes are used to represent the levels of service documentation, and they are made subclasses of a common DescriptionLevel class. Since some properties are only found for one level and one category, we need to create 6 (2x3) classes mixing categories and levels. We also need 6 corresponding properties to link each category to its 3 description levels. Finally, we need a property to link a function (or a package) to a package: a package can contain functions or other packages.
In an OWL ontology, properties de ne how information is stored (DataType properties) or how objects (instances of classes) are linked together (Object properties). Consequently, all CSPA properties are implemented using OWL DataType properties or Object properties.
How we can represent topics is not as straightforward. All topics are groups of properties bringing knowledge on the same theme, but some are more than that: they also represent objects. For instance, the Input topic represent what a function receives to operate, but a function also has input parameters which are objects on their own. It is thus logical to merge the two notions: a function will be linked to one or more objects, instances of an Input class.
On the whole, four topics (Interface, Dependencies, Input, Output) can be seen as objects: an Interface is one of potentially several ways to invoke the service, a Dependency is one thing out of many needed to use the service, an Input is an object consumed by a function, an Output is an object produced by a function). OWL classes are needed for representing each of those 4 topics.
For the other topics (Business function, Documentation, Provenance, Identication), there is no real need of OWL classes; properties could be linked directly to the function or the package class. But since there are many properties, we think that it is clearer to create classes also for these topics and link properties of a topic to their topic class, that acts as an intermediary for organizing the information. This structure intends to inform the user where to look at for a speci c information, and thus to facilitate the understanding and use of the ontology. We think the added clarity is worth the small extra complexity in the structure.
We make an exception for Identi cation: since identi cation should be fast and straightforward, properties in the identi cation topic should be accessible directly, and it is better to attach them directly than through a topic class. 3.4
According to the conclusions of the previous section, we created in the ontology a PropertyTopic class to contain property topics, and we created 7 subclasses of the PropertyTopic class, for each of the topics except Identi cation. The identi cation properties are described below.
We must take into account the interaction between property topics and levels. The BusinessFunction topic can be applied only to one level: ServiceDe nition. Provenance and Documentation can be applied to all levels, and no distinction is made between levels in regard of the content of those topics.
Dependency, Interface, Input and Output topics, on the other hand, can be applied to all levels, but properties relative to each level are di erent: the content of these topics is not the same in the di erent levels, so we have to create 12 classes combining topics and levels (4 topics and 3 levels). Each class is a subclass of the topic it refers to, and its name is the concatenation of the level name (abbreviated as De nition, Speci cation and Implementation respectively) and of the topic name. For example, the De nitionInput class is a subclass of the Input class.
As of today, the subclasses for each level for Dependency and Interface are exactly the same, but the CSPA speci cation shows that it may not stay true in the future. Table 1 illustrates the connections between topics and levels of description in CSPA.
With these di erent de nitions, we can now link one level, or all the levels, or the levels concerning only functions, etc., to properties topic. Also, to facilitate the future use of the ontology, we add a description property to every property topic, which allows to freely add descriptive text to the topic. DescriptionLevel
ServiceDe nition FunctionDe nition
ServiceSpeci cation
FunctionSpeci cation ServiceImplementationDescription
FunctionImplementation
In table 1, the lines are the OWL classes corresponding to level of description and glanularity categories. The blue cells only indicate the highest-level class to which a given topic is attached. For example, Provenance and Documentation are attached to DescriptionLevel, which is a common ancestor of all the others, and so these topics are de ned for all level and all categories. FunctionDe nition inherits the topics from DescriptionLevel and ServiceDe nition, and adds Input and Output. PackageDe nition is not represented because it has only inherited topics. 3.5
For the 4 topics referring naturally to objects that we listed before (Interface, Dependency, Input and Output), one instance can be described in more than one level. An obvious need, and thus ontology use case, is to be able to capture the relation between the corresponding objects at di erent levels. For instance, it should be easy to link with each other the di erent levels of description of an Input (e.g. a GSIM object at the de nition level and a LIM object at the speci cation level).
Di erent possibilities were considered to implement this feature, and we settled on the use of a common identi er. In order to give exibility at implementation time, we modeled the identi er as an OWL class, with subclasses for each topic (InputIdenti er, etc.). Only a label property is de ned for the identi ers, but other properties can be added in the future for more speci c identi cation.
Regarding the ranges of the topic classes, table 1 shows that we could have speci ed them very precisely. Nevertheless, we felt that it was clearer to provide topics as close as possible for each level, so that we decided to extend the range of some topics. Only business function topic is not extended to every level, since we considered that the business function was only conceptual and did not have an implementation. The goal of extending topics is not to alter CSPA speci cation, but to make it clearer (every topic present at each level), and easier to use. 3.6
As we mentioned above, the Identi cation topic has no associated topic class: in order to make theme as accessible as possible, the identi cation properties, label and version, are directly linked to the objects they quali y. They are de ned as datatype properties with range xsd:string and can be applied on DescriptionLevel and PackageOrFunction (and thus all their subclasses). A label can also be applied on Identi er, Dependencies, Interface, Input, Output classes. As a consequence, for Dependencies, Interface, Input, Output classes, a label can be given directly or via an Identi er. 3.7
We decribe in this section more classes and properties dedicated to modeling the CSPA roles, as well as the speci c properties corresponding to the topics introduced in 2.5.
Roles and provenance We introduced the CSPA roles in sub-section 2.6. To represent these roles and their action in the life-cycle of a statistical service, we use the PROV9, ORG10 and FOAF11 ontologies. The whole ontologies could be used to document provenance information, but only a few properties and classes correspond to the CSPA initial speci cation.
In the rest of the paper, the usual pre xes prov:, org: and foaf: will be used for the corresponding ontologies. The cspa: pre x will be used for the CSPA ontology.
In order to incorporate PROV, we de ne a cspa:Provenance class (the name will be precised in a future version) as a subclass of the prov:Entity class. The property prov:wasGeneratedBy allows to document an organization as a
CSPA role. We also create a cspa:Organization sub-class of prov:Organization and org:Organization (this class being itself a sub-class of foaf:Agent).
We also create a cspa:organizationName property, which is an alias of foaf:name.
Finally, we introduce 8 properties linking cspa:Provenance to each role, all sub-properties of prov:wasGeneratedBy.
For instance, one may describe a CSPA service documentation made by a
National statistical institute (NSI) in the following way (expressed in the Turtle
language[
Documentation The ontology de nes 5 properties for this topic:
{ cspa:installationGuide, which links to a foaf:Document
{ foaf:homepage, which links to a foaf:Document
{ cspa:methods, with string values
{ cspa:description, with string values
{ cspa:additionalInformation, with string values
BusinessFunction We de ne 3 speci c properties for this topic. cspa:outcomes
and cspa:restrictions are datatype properties with string values. The cspa:gsbpmSubProcess
property links to the SubProcess class in GSBPM ontology [
It should be noted that the business function topic in CSPA is not exactly
the same as in GSIM [
Dependency and Interface Since the CSPA speci cation is not very precise on the information that should be stored in these topics, and because we do not want to have too many properties, we chose in a rst approach to have a very simple structure, where a dependency or an interface is described with only two properties: a label and a description, both string datatype properties. In consequence, there is no property speci c to Dependency and Interface, except for identi ers (see above).
We also introduce a direct link between Dependency and Interface. At de nition and speci cation levels, dependencies should be broad enough not to depend on a speci c interface. At implementation level however, a direct link between dependency and interface is needed. For instance, if the service has several interfaces including a web interface, then a dependency concerning compatible browser only makes sense for the web interface.
As a consequence, we extend the cspa:implementationDependsOn property that was previously created to represent the a service implementation and a dependency, so that its domain also covers the cspa:ImplementationInterface class. Input and Output It would be possible to use for the Input and Output topics the same label/description construct that we used for Interface and Dependency, but being able to connect services together is a key point of CSPA, so that is not a recommended method.
We saw that service de nition level, Input and Output instances should be GSIM objects. Thus, we introduce a generic gsim:gsimObject class and create two object properties, cspa:gsimInput and cspa:gsimOutput with this range, de ned on the cspa:De nitionInput and cspa:De nitionOutput topic classes.
A similar construct is used for the speci cation level with CSPA LIM objects.
On a service implementation level, the way speci cation should be done is open: for example, is possible to use GSIM Process Input or a GSIM Process Output objects. At this level, it is possible to link an input or an output directly to an Interface; some parameters may indeed only have sense for a speci c interface.
Cardinality restrictions More experience with CSPA is needed in order to dene cardinality restrictions in the ontology, and we chose not to use owl:Restriction to allow for any future implementation of them. However using a property more than once would never produce non-sensical speci cation. 4
We presented in this paper the construction of an OWL ontology aiming to model the core of the Common Statistical Production Architecture speci cation, namely the di erent levels of service documentation and the organizational roles involved in the conception, building and implementation of statistical services. This work consisted in a detailed semantic analysis of CSPA, allowing to identify the main concepts in order to translate them as OWL classes and properties. We had to make some compromises and some additions to CSPA in order to build a complete and consistent ontology, but we are con dent that this will enhance the coherence between CSPA and its main pillars: GSBPM and GSIM.
The work presented here is just a rst step; it will be prolonged in di erent directions.
First, since more CSPA services are presently being developed by di erent organizations, we will shortly be able to test our model on more examples. Currently, there are only a handful of service descriptions, so a serious evaluation of the model is not possible, although we found it performed well on existing cases (see example referenced above). With more service descriptions, we will be able to evaluate our work more completely, which is likely to help us re ne the ontology.
Second, the results of our work will be presented to the CSPA sponsors, speci cally the CSPA Implementation Group which is the high-level committee in charge of maintaining CSPA. We believe that this input will be taken into consideration for a future version of CSPA.
Third, the current work is part of a broader interest in semantic business
process management (SBPM). The article by Hepp and others [
Finally, we intend to operationalize the ontology by constructing an IT system based on it. A hackathon session sponsored by the UNECE is already scheduled with colleagues from di erent countries, and one objective is to develop a graphical CSPA service editor that will produce representations conformant to the ontology presented here.