ALIGNEDaligned-project.eu/wordpress/wp-content/uploads/...0.5 22/2/2016 TCD Final Quality Check Declan O’Sullivan 1.0 24/2/2016 Release Candidate Rob Brennan 1.01 29/2/2016 Final

ALIGNED Aligned, Quality-centric, Software and Data Engineering

H2020 – 644055

D2.7 – Metamodel (Phase 2)

Project Number: 644055

Project Title: ALIGNED

Document Type: (Deliverable/Internal): Deliverable

Deliverable Number: D2.7

Deliverable Type (R/DEM/DEC/OTHER): R – Report

Workpackages Contributing: WP2

Dissemination Level (PU/CO): PU – Public

Contractual Delivery Date: Feb 2016 (Agreed with PO)

Actual Delivery Date: Feb 2016

Version: 1.01

Editor(s)/Lead Authors: Rob Brennan, Monika Solanki, Bojan Bozic

With contributions from: Christian Mader, Helmut Nagy, Christian Dirschl, Katja Eck, Kevin Feeney, Dimitris Kontokastas, Declan O'Sullivan, Jim Davies, James Welch, Jeremy Gibbons, Pieter Francois, Andreas Koller, Arkadiusz Marciniak, Odhran Gavin, Gavin Mendel-Gleason, Piotr Bledzki, Diego Esteves, Seyyed Shah, Marta Bartkowiak, Patrycja Filipowicz

Reviewers(s): Seyyed Shah

Abstract:

This document defines the ALIGNED metamodel for software and data engineering in terms of a set of modular RDF vocabularies and ontologies. It will be updated for project phase 3 in M24.

Keyword List:

Data, Software, Semantics, Ontology, Vocabulary, Linked Data

This communication reflects only the author’s view and the Commission is not responsible for any use that may be made of the information it contains.

Copyright © 2016 by the ALIGNED Consortium. The ALIGNED consortium consists of the following partners:

Trinity College Dublin

The University of Oxford

Universitaet Leipzig

Semantic Web Company GmbH

Wolters Kluwer Deutschland GmbH

Uniwersytet im. Adama Mickiewicza w Poznaniu

ALIGNED D2.7 – Metamodel (Phase 2)

ALIGNED (H2020 Project #644055) Page 2

History

Version Date Reason Revised by

0.1 12/1/2016 First Draft based on D2.2 Rob Brennan

0.2 12/2/2016

Full Internal Draft for Review based on

additional material supplied by Monika

Solanki, Christian Mader, Dimitris

Kontokostas and Bojan Bozic Rob Brennan

0.3 17/2/2016 Proof-reading review Odhran Gavin

0.4 18/2/2016 Revised Draft based on Internal Review

Seyyed Shah/Rob

Brennan

0.5 22/2/2016 TCD Final Quality Check Declan O’Sullivan

1.0 24/2/2016 Release Candidate Rob Brennan

1.01 29/2/2016 Final Release Rob Brennan

Author List

Organisation Name Contact Information

TCD Rob Brennan [email protected]

OxSE Monika Solanki [email protected]

TCD Bojan Božić [email protected]

UL Dimitris Kontokostas [email protected]

SWC Andreas Koller [email protected]

WKD Katja Eck [email protected]



Executive Summary

This deliverable documents the metamodel (which is specified as a set of linked data vocabularies/ontologies) for software and data engineering being used and developed in the ALIGNED project. These vocabularies for data-intensive system specification and governance define ways to record design intents, domain models, unified quality reports, software and data lifecycles. The ALIGNED software and data engineering tools consume and produce enterprise linked data using these vocabularies to enable tool-chain integration, semantics-driven software engineering and unified governance of these tool-chains. All of the models described here extend the W3C provenance ontology and so it forms a common upper ontology for them. The models have been developed in a modular fashion to facilitate reuse of only the applicable parts of the vocabularies for specific systems or deployments.

In addition to project-wide or generic parts of the metamodel, we describe domain-specific extensions for each ALIGNED phase 2 trial environment (the four ALIGNED use cases – JURION, Seshat, DBpedia and PoolParty). Thus, this document specifies a set of common information models or integration points for the ALIGNED phase 2 trials and documents current best practice within ALIGNED for linked data to describe data intensive systems engineering. As the project progresses, the ontologies and vocabularies described here will continue to evolve based on the trial results and further prototyping and deployments. This document will be updated in phase 3 of the project.



Contents

Executive Summary............................................................................................................................................................ 3

1 Introduction ................................................................................................................................................................ 6

2 ALIGNED Metamodel Overview .............................................................................................................................. 8

3 Design Intent ............................................................................................................................................................ 11

3.1 Introduction, Use Cases, ALIGNED Tools .............................................................................. 11

3.2 Design Intent Ontology (DIO) Overview ................................................................................ 11

3.3 Example of Use ...................................................................................................................... 13

4 Software Engineering .............................................................................................................................................. 14


4.2 Software Lifecycle Ontology (SLO) Overview ........................................................................ 14

4.3 Software Implementation Process Ontology (SIP) ................................................................ 15

4.4 Example of Use ...................................................................................................................... 16

5 Data Lifecycle and Processes .................................................................................................................................. 16


5.2 Data Lifecycle Ontology (DLO) Overview .............................................................................. 16

5.3 DataID Overview ................................................................................................................... 17

5.4 Example of Use ...................................................................................................................... 18

6 Unified Quality Reports ........................................................................................................................................... 18


6.2 Reasoning Violation Ontology (RVO) Overview .................................................................... 19

6.3 Constructing Unified Quality Reports ................................................................................... 21

7 Enterprise Information Processing (JURION) Extensions .................................................................................... 23


7.2 Enterprise Information processing Ontology Overview ....................................................... 23

7.3 Example of Use ...................................................................................................................... 25

8 E-research in the Social Sciences and Humanities (Seshat) ................................................................................ 25


8.2 Ontology Overview ................................................................................................................ 25

8.3 Example of Use ...................................................................................................................... 26

9 Crowd-sourced public datasets (DBpedia) ........................................................................................................... 27


9.2 CSPDO Ontology Overview .................................................................................................... 27

9.3 Example of Use ...................................................................................................................... 29



10 Enterprise software development (PoolParty) .................................................................................................... 30

10.1 Introduction, Use Cases, ALIGNED Tools ........................................................................... 30

10.2 CSPDO Ontology Overview ................................................................................................ 30

10.3 Example of Use .................................................................................................................. 30

11 Next Steps ................................................................................................................................................................. 32

12 References ................................................................................................................................................................ 33

Appendices ........................................................................................................................................................................ 34

List of Figures

Figure 1: The ALIGNED metamodel (Phase 2) ....................................................................................... 8

Figure 2: The Design Intent Ontology (DIO) ......................................................................................... 12

Figure 3: The Software Lifecycle Ontology (SLO) ................................................................................. 14

Figure 4: The Software Implementation Process Ontology (SIP) ........................................................ 15

Figure 5: Data Lifecycle Ontology (DLO) .............................................................................................. 17

Figure 6: DataID Core Vocabulary ........................................................................................................ 18

Figure 7: Reasoning Violation Ontology (RVO) Base Classes ............................................................... 19

Figure 8: RVO Instance and Schema Violation Classes ........................................................................ 20

Figure 9: The EIPDM Ontology for the JURION Use Case .................................................................... 24

Figure 10: The ERES Ontology for the Seshat Use Case ....................................................................... 26

Figure 11: The CSPDO ontology used for the DBpedia Use Case ........................................................ 28

Figure 12: Sample Confulence Requirements Page Conversion to DIOPP .......................................... 31

List of Tables

Table 1 : Tools and Use Cases Support for each Metamodel Group in ALIGNED Phase 2 .................. 10

Table 2: Constraints Grouping for RUT, RVO and SHACL ..................................................................... 23



1 Introduction

This document describes the second version of the ALIGNED metamodel for software and data engineering. There will be one further version (D2.8) created during the ALIGNED project.

The metamodel contains linked data ontologies/vocabularies designed to: (1) support semantics-driven software engineering techniques developed in workpackage 3, by documenting additional system context and constraints for RDF-based data or knowledge models in the form of design intents, software lifecycle specifications and data lifecycle specifications; (2) support data quality engineering techniques developed in workpackage 4, by documenting data curation tasks, roles, datasets, workflows and data quality reports at each data lifecycle stage in a data intensive system; and (3) support the development of tools for unified views of software and data engineering processes and software/data test case interlinking in workpackage 5, by providing a set of enterprise linked data vocabularies describing software and data engineering activities (tasks), agents (actors) and entities (artefacts) based on the W3C provenance ontology [1].

Provenance forms the highest layer of the metamodel, which is then partitioned into a generic model for data intensive systems and four specialised domain-specific models for different classes of data intensive system: enterprise information processing, e-research in the Social Sciences and Humanities, crowd-sourced public datasets, and enterprise software development. The first version of the ALIGNED metamodel (D2.2) focused on a formal specification of the generic model. This second version refines and elaborates the generic model, especially with the addition of unified quality reporting vocabularies, and defines the first versions of the four domain-specific models – one for each of the ALIGNED phase two trial environments.

All models are specified as a set of self-documenting Linked Data vocabularies suitable for visualisation with the Live OWL Documentation Environment tool1, with descriptive metadata based on DataID as per the ALIGNED data management plan [2], and published on the ALIGNED website2. W3C-style documentation for each metamodel vocabulary described in this deliverable is provided in the appendices and is available through the ALIGNED website. The machine-readable RDF specifications of each vocabulary and associated metadata are also publicly available through the ALIGNED website as Linked Data. For this release of the vocabularies, we have run them all through the Dacura Quality Service prototype (D3.1, D4.3) to detect and remove specification errors.

Deliverable D2.5 [3], Use Cases and Requirements phase 2, provides input to this deliverable by documenting the four ALIGNED use cases and requirements. Each ALIGNED use case can be mapped onto a single class of data intensive systems represented by a domain-specific metamodel as follows: JURION → enterprise information processing; Seshat → e-research in the Social Sciences and Humanities; DBpedia → crowd-sourced public datasets; and PoolParty → enterprise software development. By analysing the ALIGNED user needs and application scenarios, a set of requirements were defined for the metamodels presented here. The ALIGNED generic metamodel documents the common concepts across all use cases and application scenarios considered in the ALIGNED project.

1 http://www.essepuntato.it/lode

2 http://aligned-project.eu/data-and-models/



The models presented here will be a major input into the phase 2 trials of the ALIGNED project, as they will be consumed and validated by workpackages 2, 3, 4, 5 and 6 as follows: WP2 will use this model to define the ALIGNED methods specification (D2.3) for combined software and data engineering, and it will also revise this document to produce the next version of the metamodels (D2.8). WP3 will develop model-driven software engineering techniques that combine the metamodels with data intensive system data or knowledge domain models to produce system code, data transformers, and workflow specifications (D3.3, D3.4, D3.5). WP4 will produce data quality tools based on the metamodel system descriptions that enforce system integrity and automate data curation tasks (D4.3, D4.4, D4.5). WP5 will use the metamodel for describing software and data engineering tasks when integrating engineering process monitoring data to develop unified governance tools (D5.2) and for integrating the ALIGNED tools into the phase 2 trial platforms (D5.5). Finally WP6 will run validation trials on the tools produced in WPs 3, 4, and 5 that will produce feedback for the underlying capabilities of the metamodel and suggest new directions for further development or revision.

The structure of the rest of the document is as follows: Chapter 2 provides an overview of the structure of the ALIGNED metamodel; chapters 3 to 6 describe the components of generic metamodel – Design Intent, Software Engineering, Data Engineering and Unified Quality Reports; chapters 7 to 10 describe the domain-specific extensions for each phase 2 trial; and Chapter 11 reviews the next steps and future work. Finally, the appendices provide full documentation of each of the formal models developed within ALIGNED.



2 ALIGNED Metamodel Overview

The ALIGNED metamodel is a modular, layered RDF-based semantic model that describes software and data lifecycles, inter-lifecycle events, and system design intents. This supports two main activities within ALIGNED (1) it is the basis of software and data engineering tool integration within ALIGNED by specifying common data exchange formats and defining a set of extensions to the W3C Provenance ontology that are suitable for describing activities, entities, and actors in software and data engineering processes; and (2) the metamodel is used as a source of system specifications and context that acts as an input to model-driven engineering processes and tools developed within WP3 (Semantics-Driven Software Engineering). For activity 1, this provenance information is additionally used in ALIGNED to support common governance of software and data engineering processes.

In phase 2 of ALIGNED, we focus on the flow of requirements from users into software and data engineering (captured as design intents as well as engineering specifications), connecting data quality tool-chains and enabling cross-lifecycle connections between data quality activities and software quality activities (using unified error reports). phase 2 activities have also resulted in the development of domain-specific extensions to the metamodel for each of the ALIGNED use cases.

Figure 1: The ALIGNED metamodel (Phase 2)

Figure 1 illustrates the ALIGNED metamodel split into the provenance, generic metamodel, and domain-specific extensions layers. As can be seen from the figure we have not specified all parts of the model ourselves, but instead import existing specifications where available. At the top layer, the W3C provenance standard forms the baseline for all our specifications and all our models extend it in some way. The split of the ALIGNED metamodel between a



generic layer and a domain specific extensions layer allows rapid evolution of domain-specific extensions for the ALIGNED use cases/trial environments (JURON, Seshat, DBpedia, PoolParty) based on a stable set of core concepts modelled in the generic metamodel. As the project progresses these extensions will be evaluated and incorporated into the generic metamodel if they prove valuable or more widely applicable than a single domain.

The generic metamodel documents common concepts used in data-intensive systems engineering as a set of Linked Data vocabularies/ontologies. These are grouped as follows:

Design intent: This model is used to document the design decisions about data

intensive system artefacts such as requirements, designs or datasets. It is based on

the design intent ontology (DIO), which allows users to express the design intent or

design rationale while undertaking the design of an artefact.

Software engineering: This model defines the major agents (e.g. project roles),

activities (e.g. lifecycle stages), and entities (design artefacts) involved in a software

engineering project and their relations with a special focus on capturing the

engineering lifecycle. Two ontologies make up this model – the software process

ontology (SPO) and the software implementation processes ontology (SIP).

Data engineering: As software engineering above but with a focus on data

engineering and data lifecycles. Two ontologies are used – the data lifecycle ontology

(DLO) defined within ALIGNED and the DataID ontology, defined by ALIGNED for the

DBpedia association, for describing datasets.

Unified quality reports: Defines a unified reporting representation for data quality

metrics, ontology reasoning errors, test cases, and test case results based on the

W3C SHACL reporting vocabulary. It is based on four ontologies/vocabularies, three

of which are externally developed: W3C SHACL, W3C Data Quality, and University of

Leipzig’s test-driven RDF validation ontology; and one ontology developed within

ALIGNED: the reasoning violation ontology (RVO).

Domain data model: This describes the domain of the data-intensive application

being developed and is specific to that application, e.g. the Seshat ontology for

historical time-series describing human societies. It is not defined further in this

document.

The lower layer includes the domain-specific extensions to the metamodels. ALIGNED has developed four domain-specific metamodels based on each of our use cases, with a focus on model elements needed for the ALIGNED phase 2 trials:

Enterprise information processing: extensions and models for the JURION use case.

E-research in the Social Sciences and Humanities: extensions and models for the

Seshat use case.

Crowd-sourced public datasets: extensions and models for the DBpedia use case.

Enterprise software development: extensions and models for the PoolParty use

case.

Table 1 summarizes the metamodel support for each of the ALIGNED tools and use cases in phase 2 of the project. The domain-specific metamodels are excluded from this table as they



each map to one use case and any tool which can support the base models for that use case can also support the domain-specific extensions. Further details on the use cases and tools supported can be found in sections 3-10 of this document which provide more details on each ontology and also the phase 2 trial and tool requirements sections of ALIGNED deliverable D2.5 Use Cases and Requirements [3].

Metamodel Ontology Group:

Use Case Design Intent

Software Engineering

Data Engineering

Unified Quality Reports

Domain Data Model

JURION - X X X X

Seshat - - X X X

DBpedia - - X X X

PoolParty X X - X -

Tool

RDFUnit - - - X X

Unified Governance X X X X -

Dacura3 - - X X X

Model Mapper - - X X X

Model Catalogue / Semantic Booster

- - - - X

Table 1 : Tools and Use Cases Support for each Metamodel Group in ALIGNED Phase 2

Both the generic metamodel ontologies developed within ALIGNED and the domain-specific model extension models are further described in the following sections of this document. Each section motivates the use of the ontology within ALIGNED with reference to our use case document, and provides an overview of the ontology features and an example of it in use. Ontologies imported by ALIGNED are not described in detail here.

In addition to the overviews provided in the main body of this document, the full ontology specifications for each of the new ontologies developed within the ALIGNED project are provided as appendices. The ontology documentation and source is available through the ALIGNED project website4.

3 This framework includes D

4 http://aligned-project.eu/data-and-models/



3 Design Intent

3.1 Introduction, Use Cases, ALIGNED Tools

Design intent is captured using a single ontology, the DIO (Design Intent Ontology), which is developed within ALIGNED. DIO provides a means to capture the decision-making process behind software and data artefacts in a data-intensive system. It also provides a unified, high-level model of engineering artefacts such as designs, requirements, evaluations and actors that are linked to W3C PROV.

Use cases: DIO is part of the requirements engineering infrastructure for the PoolParty use case.

ALIGNED tools: DIO is consumed by the unified governance tool (D5.2). DIO is generated by the JIRA and Confluence extraction tools in the PoolParty use case (D5.5).

3.2 Design Intent Ontology (DIO) Overview

The Design Intent Ontology (DIO) is a generic ontology that provides the conceptualisation needed to capture the knowledge generated during various phases of the overall design lifecycle [4]. It is illustrated in Figure 2.

It provides definitions for design artefacts such as requirements, designs, design issues, solutions, justifications, and evidence, and relationships between them, to represent the design process and how these things lead to design outcomes. It draws upon the paradigms of IBIS (Interactive Intent-Based Illustration), argumentation and design rationale. It is linked to W3C PROV by defining the actors in the design process as PROV agent, and the design artefacts themselves are PROV entities. However, DIO uses a modularised version of PROV-O, based on syntactic locality.

DIO makes few assumptions about the design process used, as the definitions of these activities properly belongs in the software lifecycle and data lifecycle models. The Figure below illustrates the conceptual entities in DIO and their relationships.

Full ontology documentation is available via the LODE service and persistent URI5, through the ALIGNED website and in the appendix 1 of this document.

5 http://www.essepuntato.it/lode/owlapi/ https://w3id.org/dio#

http://www.essepuntato.it/lode/owlapi/http:/purl.org/dio/



Figure 2: The Design Intent Ontology (DIO)



3.3 Example of Use

A full example of DIO in use is provided later in the specific case of the PoolParty domain-specific extensions in section 10.3.

A basic example is recoding of the decision making process in an engineering process tool such as an issue tracker or trouble-ticketing system. In this case it is useful to collect information on the origin of issues, the evidence used in decision making and the set of potential solutions available, in order to answer questions such as: which requirements are being fulfilled by a particular solution? What are the justifications for a proposed solution? Which agents supported a particular solution?

In this case we may have a set of RDF assertions, e.g. using the model fragment as follows, to answer these engineering process questions. Here an open, blocking bug report called ex:bug_01 has been identified as a design issue to be addressed and two potential solutions have been identified and linked to the bug. The first solution, ex:solution_1 is also described here in the RDF with an identifier and a free text description. The solution is linked to an argument and a justification. The justification is attributed to a specific actor in the design process, ex:joeBloggs, and two other actors are identified as supporting this solution. Finally DIO provides an ability to link the justification to some evidence, e.g. a unit test result, that supports this solution.

ex:bug_01 a dio:DesignIssue;

dio:hasStatus dio:open;

dio:hasPriority dio:blocker;

dio:hasAlternativeSolution ex:solution_1;

dio:hasAlternativeSolution ex:solution_2.

ex:solution_1 a dio:Solution;

dio:description “Implement bugfix in javascript”;

dio:hasJustification ex:justification_01;

dio:hasArgument ex:argument_01.

ex:justification_01 a dio:Justification;

prov:wasAtributedTo ex:joeBloggs;

dio:supportedBy ex:alice;

dio:supportedBy ex:bob;

dio:hasEvidence ex:evidence_01;

dio:description “Javascript is already used for all

client-side interactions in product.”



4 Software Engineering


Our W3C PROV-based model of software engineering processes is split into two ontologies: the software lifecycle ontology (SLO) and the software process implementation ontology (SIP). SLO provides a simple generic pattern for specifying processes and is based on the ISO/IEC 12207 standard for systems and software engineering. SIP extends SLO to specify a set of standard terms for typical software engineering processes and phases such as architectural design and requirements analysis. SIP also imports existing ontologies from SEON6 and the software ontology (SWO) that describe many standard terms in the software engineering domain e.g. various implementation languages like JavaScript, C, and so forth. Together, these ontologies give us a terminology for describing software engineering that is linked to W3C PROV, and so is suitable for recording lifecycle events or tool activities for consumption by ALIGNED unified governance tools.

Use cases: SIP and SLO are part of the unified governance infrastructure for the JURION and PoolParty use cases.

ALIGNED tools: SIP and SLO are consumed by the unified governance tool (D5.2).

4.2 Software Lifecycle Ontology (SLO) Overview

The Software Lifecycle Ontology (SLO) is the top level ontology for describing a process in the lifecycle of software.

The ontology conforms to the ISO/IEC 12207 standard for systems and software engineering — software life cycle processes. The terminology used in the ontology conforms to ISO/IEC TR 24774:2010(E) [5]. All subprocesses will require to import this module.

Figure 3: The Software Lifecycle Ontology (SLO)

6 http://www.se-on.org/

http://www.se-on.org/



Figure 3 illustrates the conceptual entities in SLO. The core concept is a SoftwareLifecyleProcess which can be decomposed into sub-processes, tasks and activities. The SIP ontology (see section 3.2.2) builds on this basic framework to describe standard software engineering processes e.g. requirements analysis and architectural design.

Full ontology documentation is available via LODE,7 through the ALIGNED website and in appendix 2 of this document.

4.3 Software Implementation Process Ontology (SIP)

The purpose of the Software Implementation Process Ontology is to provide a set of conceptual entities to represent standard software engineering processes. This ontology imports and builds upon the ALIGNED Software Lifecycle Ontology (SLO) as the basic description of a process. It also utilises concepts defined in the SEON (Software Evolution ONtologies)8 and the Software Ontology (SWO)9.

Figure 4: The Software Implementation Process Ontology (SIP)

The basic concepts of the SIP ontology are illustrated in figure 4. It shows the definition of basic software engineering processes and activities such as requirements analysis, design,

7 http://www.essepuntato.it/lode/http://aligned.cs.ox.ac.uk/ontologies/slo

8 http://www.se-on.org/

9 http://purl.obolibrary.org/obo/swo.owl

http://www.essepuntato.it/lode/http:/aligned.cs.ox.ac.uk/ontologies/slo



implementation, and integration in terms of SLO activities and processes. Full documentation of the ontology is available in appendix 4 of this document.

4.4 Example of Use

See the JURION domain-specific extensions (section 7.3) for an example of how SIP/SLO are being used within ALIGNED.

5 Data Lifecycle and Processes


Our W3C PROV-based model of data engineering processes is described by two ontologies: the data lifecycle ontology (DLO) developed within ALIGNED; and DataID which was originally developed within the FP7 project LIDER10, and whose development is continued by AKSW/KILT @ InfAI (ALIGNED partner UL) within ALIGNED. DLO which provides a direct extension of PROV to describe data engineering actors (e.g. Data Engineer), activities (e.g. Quality Analysis) and entities (e.g. Data Sources). DLO’s data activities are based on the eight phases of the FP7 LOD2 project’s Linked Data lifecycle.11 DataID provides a comprehensive framework for describing linked data datasets and their different manifestations.

Use cases: DLO and DataID are part of the unified governance infrastructure for the JURION, Seshat and DBpedia use cases. DataID is used to describe all ALIGNED datasets and vocabularies/ontologies we publish on the web as part of our data management plan (D7.11).

ALIGNED tools: DLO and DataID are consumed by the unified governance tool (D5.2). Dacura (D5.3, D4.5) produces data lifecycle PROV records according to DLO.

5.2 Data Lifecycle Ontology (DLO) Overview

This ontology provides a description of the data lifecycle for Data. It captures various processes involved in the lifecycle of data and answers the following questions: What lifecycle stage is a specific dataset or data item currently in? What is the appropriate widget or form to display this data item in for a specific user role, given the data item’s state (lifecycle stage)? Which agents, processes, and entities are involved in the lifecycle of a specific entity?

The purpose of the Data Lifecycle Ontology is to provide a set of conceptual entities, agents, activities, and roles to represent the general data engineering process. Furthermore, it is the basis for deriving specific domain ontologies which represent lifecycles of concrete data engineering projects such as DBpedia or Seshat.

DLO uses the W3C PROV ontology represented by the classes Role, Person, Entity, and Activity. It uses the Process class which is derived from Activity to implement the Linked Data Stack lifecycle stages as subclasses. This allows the user to represent linked open data activities in the data lifecycle metamodel. In addition, datasets, data sources and data repositories have been modelled. For datasets, it imports the DataID definition of a dataset,

10

FP7 Project #610782, http://www.lider-project.eu/ 11

http://stack.linkeddata.org/



as it is a broad definition that goes beyond representing only RDF-based datasets. Figure 5 shows the main classes of the data lifecycle model. We define the Process class which is derived from Activity to implement the Linked Data Stack lifecycle stages [6] as subclasses. In addition, we have modelled datasets, data sources and data repositories.

Figure 5: Data Lifecycle Ontology (DLO)

The full documentation and OWL ontology file of the ALIGNED data lifecycle model can be downloaded12. The documentation is also provided in appendix 3 of this document.

5.3 DataID Overview

The DBpedia DataID core vocabulary is a meta-data system for detailed descriptions of datasets and their different manifestations. Established vocabularies like DCAT, VoID, PROV-O and FOAF are reused for maximum compatibility, in order to establish a uniform and accepted way to describe and deliver dataset metadata for arbitrary datasets and to put existing standards into practice. In addition, DataID can describe the relations of Agents (like persons or organizations) to datasets with regard to their rights and responsibilities.

Due to the growing complexity and different usage purposes, we modularised the DataID ontology in a core and multiple mid-layer ontologies. While the core ontology is mandatory for any of the mid-level ontologies presented, none of those are required for describing data. That being said, in many use cases some or all of the mid-level ontologies will be a useful extension.

The DataID core vocabulary (figure 6) describes datasets (based heavily on the DCAT ontology), as well as their relation to agents like persons or organizations with regard to their rights and responsibilities.

12

http://www.essepuntato.it/lode/owlapi/https://w3id.org/dlo

http://www.essepuntato.it/lode/owlapi/https:/w3id.org/dlo



Figure 6: DataID Core Vocabulary

The full documentation and OWL ontology file of DataID can be downloaded from DBpedia13, the DataID landing page at DBpedia14 and through the ALIGNED website. The documentation is also provided in appendix 3 of this document.

5.4 Example of Use

See the Seshat domain-specific extensions section of this document for an example of the Data engineering vocabularies in action.

6 Unified Quality Reports


Unified error reporting is needed to enable merging quality reports from multiple data quality tools within a data engineering tool-chain, and to transfer quality reports between the data and software engineering processes (cross-domain tool-chain integration and unified governance). The ALIGNED unified quality reports build upon three established or emerging vocabularies for linked data quality: the W3C SHACL reporting vocabulary [7]; the W3C Draft Data Quality Vocabulary (DQV) [8]; and University of Leipzig’s Test-Driven Data Validation Ontology (RUT)15 [9]. The SHACL reporting vocabulary is being designed by the

13

http://dataid.dbpedia.org/ns/core.html 14

http://dbpedia.org/projects/dbpedia-dataid#Data%20model 15

http://rdfunit.aksw.org/ns/core

http://dataid.dbpedia.org/ns/core.html



W3C (with ALIGNED input) as a mechanism for reporting on data test results. DQV is emerging as an extension to DCAT (the W3C data catalogue specification) within the W3C that provides the ability to publish, exchange and consume quality metadata for every step of a dataset's lifecycle. It defines a set of quality metric identifiers. RUT defines provenance-based links to test cases and test case results. ALIGNED enhances these vocabularies with a new vocabulary to describe ontology reasoning violations (RVO) detected in an ontology and a framework for integrating all four vocabularies into a unified reporting framework.

Use cases: Unified quality reports are used in the JURION and Seshat use cases.

ALIGNED tools: RUT, SHAQL and DQV reports are produced by RDFUnit (D5.4), RVO is generated by the Dacura Quality Service (D4.3). All are consumed by the unified governance tool (D5.2).

Note: SHAQL, DQV and RUT are not described in this document as they are defined outside ALIGNED. Please refer to the references and links provided for further details on them.

6.2 Reasoning Violation Ontology (RVO) Overview

The purpose of RVO is to enable a reasoner to describe reasoning errors detected in an input ontology, in order to facilitate the integration of reasoners into semantic web tool chains.

Figure 7: Reasoning Violation Ontology (RVO) Base Classes

It is defined as a simple OWL 2 ontology that is amenable to RDFS-based interpretations or use as a linked data vocabulary without any dependence on reasoning. A permanent identifier for the ontology has been registered with the W3C permanent identifier community group. The full source of the ontology is published online. This ontology is used to describe RDF and OWL reasoning violation messages in the Dacura Quality Service. These are generated by running an RDF/RDFS/OWL-DL reasoner over an RDF-based ontology model and allowing the Dacura quality service to report any integrity violations detected at schema or instance level. These violations report areas where the input model is logically inconsistent or breaks RDFS/OWL semantics or axioms. Violations may be reported as based on open world or closed world assumptions. The open world is the default OWL semantics



and can typically only detect a limited number of problems due to incomplete knowledge. The closed world interpretation assumes that you have provided all relevant aspects of the model and is able to detect a much wider range of violations, e.g. missing or misspelled term definitions. This is often useful during ontology development or in a system that interprets OWL as a constraint language.

RVO will allow machine-readability and interpretation of detailed reasoning error messages. Furthermore, this would enable building tools to verify the OWL DL compliance of an ontology, find out which best practice requirements the ontology meets or violates, track the impact of interpreting the ontology in open and closed world contexts, identify the exact position of violations, and support intelligent visualisation of errors. The structure of the base RVO classes are shown in figure 7.

Figure 8: RVO Instance and Schema Violation Classes



RVO class and instance violations are shown in figure 8. Class violations are used for reporting issues regarding the TBox and instance violations ABox in general. Therefore, class violations are reported when e.g. property domains are missing, subsumption errors are detected, or class and property cycles are found. Instance violations show instances which are not elements of valid classes, cardinalities which are incorrect, property constraints that are violated, literals and objects which are confused, etc.

The full documentation and OWL ontology file for RVO can be downloaded using the LODE documentation service and the persistent URI for the ontology16. The documentation is also provided in appendix 5 of this document.

6.3 Constructing Unified Quality Reports

The unified quality report will be based on the SHACL reporting format. The tools we will generate will consume SHACL-based reports, enrich them with provenance metadata and will return high level dataset quality reports.

Validation Provenance Metadata

The validation provenance metadata will be based on PROV and the Test-Driven RDF Validation Ontology, and, in particular, rut:TestExecution. Each rut:TestExecution contains provenance metadata for the validation. For example, start/end time, triples checked, violations found, tests run, etc. The violation results are of type sh:ValidationResult and are linked to the TestExecution using prov:wasGeneratedBy. The following RDF snippets contain only the necessary triples required for the DQV report generation.

ex:testExecutionIRI a rut:TestExecution, prov:Activity; # ... rut:totalTriples “10”^^xsd:Integer.

SHACL validation instances

Each violation instance adheres to the SHACL vocabulary and is of type sh:ValidationResult. SHACL defines different properties that can be attached to a validation result. For example, sh:message, sh:focusNode, sh:object, etc. For the purpose of the DQV report, we focus only on sh:sourceConstraint which points to the constraint that lead to this violation. For example:

<v1> a sh:ValidationResult ; #... prov:wasGeneratedBy ex:testExecutionIRI ; sh:sourceConstraint rdqv:CardinalityConstraint .

SHACL is still in progress and it is not yet clear if SHACL will define persistent IRIs for each SHACL constraint. On the other hand, even if it did, we do not want to be limited by the SHACL constraints and thus, we created a general constraint mapping framework. Table 1 provides mappings between our proposed constraint categories and RDFUnit/RUT, RVO and existing core SHACL constraints. Each constraint from the table corresponds to a DQV quality metric (dqv:Metric) that we measure using a configuration file. For instance: rdqv:CardinalityConstraint is mapped to rdqv:CardinalityMetric. Constraints that do not exist

16

http://www.essepuntato.it/lode/owlapi/https://w3id.org/rvo

http://www.essepuntato.it/lode/owlapi/https:/w3id.org/rvo



in our configuration file are mapped to rdqv:UnclasifiedMetric. Violations that do have a sh:sourceConstraint will be mapped to rdqv:UndefinedMetric.

The aforementioned validation result, for instance, would provide the following DQV quality report:

ex:testExecutionIRI dqv:hasQualityMeasure ex:qm1.

ex:qm1 dqv:computedOn ex:testExecutionIRI ; dqv:hasMetric rdqv:CardinalityMetric dqv:value "0.1"^^xsd:double . # 1 instance / 10 triples

The unified report generation is implemented through the RDFUnit framework. It is implemented as a separate Maven module that be either used directly as a standalone tool or as a library dependency. The defined metrics are available on the RDFUnit home page17.

Constraint RDFUnit Generators RVO Violation Class SHACL

Cardinality Constraint

rutg:OWLCOMPL rutg:OWLCARD rutg:OWLCARDEX rutg:OWLCARD0 rutg:OWLCARD-MIN rutg:OWLCARDEX-MIN rutg:OWLCGARD-MAX rutg:OWLCARD-MAX0 rutg:OWLQCARD rutg:OWLQCARDEX rutg:OWLQCARD0 rutg:OWLQCARD-MIN rutg:OWLQCARDEX-MIN rutg:OWLQCARD-MAX rutg:OWLQCARD-MAX0 rutg:OWLFUNC

rvo:NotFunctionalProperty

sh:minCount sh:maxCount sh:qualifiedValueShap sh:qualifiedMinCount, sh:qualifiedMaxCount

Owl Restriction Constraint -

rvo:NotRestrictionElement rvo:DataInvalidAtDatatype

Domain Constraint

rutg:RDFSDOMAIN rutg:RDFSDOMAIN-MISS

rvo:NoPropertyDomain rvo:EdgeOrphanInstance

Range Class Constraint

rutg:RDFSRANGEC rutg:RDFSRANGEC-MISS rvo:NoPropertyRange

sh:class sh:classIn sh:directType

Range Datatype Constraint

rutg:RDFSRANGEL rutg:RDFSRANGED rutg:RDFSRANGENL

rvo:DataInvalidAtDatatype rvo:NotBaseTypeElement

sh:datatype sh:datatypeIn

Value Constraint

rvo:InvalidEdge

sh:equalssh:hasValue sh:in sh:lessThan sh:lessThanOrEquals sh:valueShape sh:minLength sh:maxLength sh:minExclusive

17

http://rdfunit.aksw.org/ns/rdqv

http://rdfunit.aksw.org/ns/rdqv



sh:minInclusive sh:maxExclusive sh:maxInclusive sh:nodeKind sh:notEquals sh:pattern

Value Language Constraint

rutg:RDFLANGSTRING sh:uniqueLang

Type Disjoint Constraint

rutg:OWLDISJC1 rutg:OWLDISJC2 rutg:OWLALLDISJC

rvo:ObjectInvalidAtClass

PropertyDisjoint Constraint

rutg:OWLDISJP rutg:OWLALLDISJP

ComplementOf Constraint

Inverse Functional Property Constraint

rutg:OWLINVFUNC rvo:NotInverseFunctionalProperty

Deprecated Class Constraint

rutg:OWLDEPRECATEDP

irreflexive Property Constrains

rutg:OWLIRREFLEXIVE

Asymmetric Property Constraint

rutg:OWLASYMMETRICPROP

Table 2: Constraints Grouping for RUT, RVO and SHACL

7 Enterprise Information Processing (JURION) Extensions


There is one ontology defined for the JURION use case, the enterprise information processing ontology (EIPDM), to explore the applicability of the ALIGNED generic metamodel to the JURION system in the phase 2 trials. Where necessary the generic models SLO, and DLO have been extended to account for the actors, entities and activities in the JURION domain.

Use cases: Deployed in JURION use case.

ALIGNED tools: EIPDM is consumed by the unified governance tool (D5.2).

7.2 Enterprise Information processing Ontology Overview

The initial information gathered to build the domain-specific enterprise information processing metamodel is based on the JURION use case. The JURION use case includes both



processes for data and software engineering, and therefore uses the data lifecycle ontology and the software lifecycle ontology.

The ontology models mandatory data requirements for specific processes, and checks if they are fulfilled. The location of error occurrence within the process is registered and the type of error or inconsistency asserted. Furthermore, we capture how many errors occurred, which dataset they were detected in, what was responsible for it, who fixed it, when it was fixed, and how long the repair took. Captured information about the dataset include publishing, versioning, and properties. Functionalities are associated to specific datasets and changing of data is tracked. Other areas of interest are links and how they behave especially when linking eternal data sources as well as mapping ontologies and information of processes about external data changes.

Figure 10 illustrates the EIPDM ontology. The main features are a set of new software engineering process outcomes, data engineering roles and data engineering activities. Transformation is a new concept added to model the combined lifecycle of software and data artefacts within JURION.

The full documentation and OWL ontology file for EIPDM can be downloaded from the LODE site using the persistent URI of the ontology18 and the ALIGNED website. The documentation is also provided in appendix 6 of this document.

Figure 9: The EIPDM Ontology for the JURION Use Case

18

http://www.essepuntato.it/lode/owlapi/https://w3id.org/eipdm

http://www.essepuntato.it/lode/owlapi/https:/w3id.org/eipdm



7.3 Example of Use

If a data or software engineering tool deployed in JURION wishes to create an audit trail of its activities, for example for visualisation by the ALIGNED unified governance tool, then it may record its activities using a combination of PROV and the ALIGNED ontologies that extend PROV in a fashion similar to this (Turtle notation):

ex:releaseCandidate_1 a eipdm:Transformation ;

prov:generatedAtTime “20151010”^^xsd:date

dlo:consumes ex:jurionGeonamesSnapshot2015 ;

dlo:consumes ex:jurionDbpediaDataset2015 ;

slo:hasProcessOutput ex:schematest_1.

ex:schematest_1 a eipdm:SourceCode ;

eipdm:hasVersion [ a eipdm:Version;

eipdm:hasMajor “2”^^xsd:nonNegativeInteger;

eipdm:hasMinor “34”^^xsd:nonNegativeInteger;

eipdm:hasPatch “71”^^xsd:nonNegativeInteger;

eipdm:hasBuildMetaData “CRE-F-667 Closed” ].

This example describes a new JURION Transformation called release candidate 1 that consumes two datasets, was created on the 10/10/2015 and produces a process output of some source code that is version stamped.

Having a common vocabulary for audit trails of tool activities that include both software and data engineering enable comprehensive dashboarding of JURION development processes.

8 E-research in the Social Sciences and Humanities (Seshat)


There is one ontology defined for the Seshat use case, the e-research in the social sciences and humanities ontology (ERES), to explore the applicability of the ALIGNED generic metamodel to the Seshat system in the phase 2 trials. ERES extends the generic data lifecycle model (DLO) to account for the actors, entities and activities in the Seshat domain.

Use cases: Deployed in Seshat use case.

ALIGNED tools: Dacura (D4.3, D4.5, D5.3) produces ERES and it is consumed by the unified governance tool (D5.2).

8.2 Ontology Overview

The purpose of the ALIGNED E-research in the Social Sciences and Humanities domain-specific metamodel is to provide a set of concrete entities, agents, activities, and roles to represent the data engineering process for this domain. It is based on the Seshat use case within ALIGNED. It specialises the ALIGNED generic Data Lifecycle Ontology (DLO) and imports the W3C PROV ontology.

This model adds support for specific external data sources for datasets like wikis and webpages. It adds new entities to represent candidate data for inclusion in a dataset, reports of historical events, and historical interpretations created by domain experts. It extends the set of data lifecycle processes to include data curation activities such as manual



data extraction and data publishing. Finally new roles are defined for all the actors in the Seshat databank project: readers, experts, research assistants and so forth, that work in the Seshat semi-automated data curation pipelines or workflows.

Figure 11 illustrates the concepts found in the ontology. A full specification of the model is available in appendix 5, the ALIGNED website and online19.

Figure 10: The ERES Ontology for the Seshat Use Case

8.3 Example of Use

A common Seshat use case is the extraction of candidate data from the Seshat wiki for further processing in the Dacura platform. An audit trail of this activity may be constructed as follows by the Dacura tools (turtle notation).

This Turtle describes the case where a candidate set of data for a historical polity, the Roman Empire, was manually extracted from a private wiki page used for initial data collection by research assistants in Seshat. The candidate data is recorded, attributed to a specific data processing task (:aExtraction), labelled, attributed to an actor (:robBrennan), given a generation time and the entity it was derived from (the wiki page :itRomPrWikiPage) is identified. The extraction activity is further categorised as a manual one and labelled. Then information is provided on the original wiki page itself (:itRomPrWikiPage), the

19

http://www.essepuntato.it/lode/owlapi/https://w3id.org/sdo

http://www.essepuntato.it/lode/owlapi/https:/w3id.org/sdo



research assistant that completed it is noted and the expert who validated is identified. The actors are all assigned labels and categorised by their data management roles in Seshat – a RA, a domain expert and a data architect.

Recording this information in Seshat is important to be able to trace the origin and authority of facts as they appear in the final, curated dataset. For example a consumer of the data may wish to disregard the opinions of specific experts for differing interpretations.

data:itRomPr a eres:Candidate;

rdfs:label "Candidate generated from Roman Empire-

Principate wiki page";

prov:wasDerivedFrom :itRomPrWikiPage;

prov:wasGeneratedBy :aExtraction;

prov:wasAttributedTo :robBrennan;

prov:generatedAtTime "2015-07-28T13:35:23Z"^^xsd:dateTime.

ex:aExtraction a eres:ManualExtraction;

rdfs:label "Rob's manual extraction activity".

ex:itRomPrWikiPage a eres:Wiki

rdfs:label "The Roman Empire-Principate wiki page,

http://seshat.info/ItRomPr".

eres:ra :edwardALTurner;

eres:expert :garrettFagan.

ex:robBrennan a eres:DataArchitect;

rdfs:label "Rob Brennan".

ex:edwardALTurner a eres:ResearchAssistant;

rdfs:label "Edward A L Turner".

ex:garrettFagan a eres:Expert;

rdfs:label "Garrett Fagan".

9 Crowd-sourced public datasets (DBpedia)


There is one ontology defined for the DBpedia use case, the crowd-sourced public datasets ontology (CSPDO) to explore the applicability of the ALIGNED generic metamodel to the DBpedia use case in the phase 2 trials. CSPDO extends the generic data lifecycle model (DLO) to account for the actors, entities and activities in the DBpedia domain, with a focus on interlinking, validation and extraction (as this is the scope of the DBpedia phase 2 trial in ALIGNED).

Use cases: Deployed in DBpedia use case.

ALIGNED tools: RDFUnit (D4.4, D5.4) and the Model Mapping Tool (D3.4) produce CSPDO and it is consumed by the unified governance tool (D5.2).

9.2 CSPDO Ontology Overview

This ontology is used to describe the domain-specific extensions to the ALIGNED data lifecycle model ontology (DLO) and software lifecycle ontology (SLO) for crowd-sourced



public datasets based on the DBpedia use case within the ALIGNED project. Over time, generic features may be migrated to the upper ontology.

The current scope of this ontology is to support extensions needed for DBpedia scenarios within phase 2 of the ALIGNED project. Thus, there is a focus on the validation activities. DBpedia is a large-scale project of extracting unstructured & semi-structured data from different Wikipedia language editions to RDF. This extraction is achieved using a modular extraction framework that is customized to handle multilingualism and structural differences between different Wikipedia language editions. The latest DBpedia release (v. 2016) generated a total of three billion facts from 125 localized versions. As Wikipedia evolves over time, the code should be able to adapt to these changes. However, identifying errors at this data scale becomes very hard, and validation workflows must be established that will ensure the quality of the extracted data.

ALIGNED is tackling these challenges with data validation and interlink validation tools that communicate their results though the ALIGNED vocabularies.

Figure 12 illustrates the concepts found in the ontology. A full specification of the model is available in appendix 6, the ALIGNED website and online20.

Figure 11: The CSPDO ontology used for the DBpedia Use Case

20

http://www.essepuntato.it/lode/owlapi/https://w3id.org/eipdm/cspdo

http://www.essepuntato.it/lode/owlapi/https:/w3id.org/eipdm/cspdo



9.3 Example of Use

The prototype Model Mapper tool (D3.4) uses CSPDO to record interlink validation processing on the DBpedia release candidate. This enables its activities to be shown in the Unified Governance tool (D5.2), and for other data engineering tools to co-ordinate with it in a toolchain. For example, as shown here, for the exchange of which mappings failed the validation test. This allows another tool to take corrective action on these mappings or to present them to a user.

The RDF shows the description of an interlink validation run which identifies the specific tool used for validation, the three datasets consumed (the linkset, DBpedia and Geonames) and the validation report produced (ex:interlink_validation_report_1). The datasets are identified as DataID datasources and thus could have a large amount of meta-data recorded about them. The actor who initiated the interlink validation is recorded and classified as a SysAdmin. The interlink validation report itself identifies two invalid mappings in the mapping set analysed, in the first case both ends of the mapping are incorrect (probably missing from the mapped datasets) and the second mapping error identifies only one mal-formed resource.

ex:interlink_val_1 a cspdo:InterlinkValidation ;

dlo:isSupportedBy ex:interlink_validator ;

dlo:consumes ex:dbpedia_geonames_interlinks_2015 ;

dlo:consumes ex:dbpedia_dataset_2015 ;

dlo:consumes ex:geonames_dataset_20151010 ;

dlo:produces ex:interlink_validation_report_1 .

ex:dbpedia_dataset_2015 a dlo:DataSource .

ex:geonames_dataset_20151010 a dlo:DataSource .

ex:person_1 a dlo:SystemAdmin ;

dlo:initiates ex:interlink_val_1 .

ex:model_mapper a dlo:DataSoftwareAgent ;

dlo:supports ex:interlink_val_1 .

ex:interlink_validation_report_1 a

cspdo:InterlinkValidationReport ;

prov:wasGeneratedBy ex:interlink_val_1 ;

ex:invalidMapping1 [ ex:mapId ex:mapping_1 ;

ex:invalidResource <resource_1> ;

ex:invalidResource <resource_2> ] ;

ex:invalidMapping2 [ ex:mapId ex:mapping_2 ;

ex:invalidResource <resource_3> ] ;

prov:generatedAtTime “20151010”^^xsd:date .



10 Enterprise software development (PoolParty)


There is one ontology defined for the PoolParty use case, the Applying the DIO Design Pattern to PoolParty ontology (DIOPP), to explore the applicability of the Design Intent Ontology from the ALIGNED generic metamodel to the PoolParty Requirements Engineering for Enterprise Software Development use case in the phase 2 trials. DIOPP provides a set of extended DIO classes and properties, to represent customer requirements stored in Confluence and bug reports from JIRA. By defining an ontology to integrate the requirement specifications and issues emerging from their implementation, it becomes possible to generate unified views of agents, activities, events, intentions and roles that further enable the governance of the joint software and data engineering processes on the PoolParty product.

Use cases: Deployed in PoolParty use case.

ALIGNED tools: The Confluence and JIRA connectors developed for the PoolParty phase 2 trial environment (D5.5) produce DIOPP and it is consumed by the unified governance tool (D5.2).

10.2 CSPDO Ontology Overview

For the PoolParty use case, SWC and OxSE designed an ontology that defines additional specializations of the DIO elements so that the requirements of the SWC unified governance use case can be captured. For example it provides classes to model a JIRA21 bug report, a GRIPS requirement, acceptance test criteria, software product components and preconditions.

This mapping ontology, DIOPP, is published online, on the ALIGNED website and full documentation is provided in appendix 7.

10.3 Example of Use

DIOPP has been implemented in a tool that connects to the Confluence and JIRA REST APIs and extracts information from either the received JSON responses or by parsing Confluence HTML pages which are structured according to SWC-proprietary templates. This information is expressed by the tool in RDF, using the DIO and DIOPP ontologies and written to the local file system.

The extraction tools were then wrapped in a UnifiedViews22 Data Processing Unit so that it can be integrated into ETL processes, allowing, for example, regular extraction at a certain time and storing it into a remote triple store.

Here we provide an example on how the conversion of existing requirements and issues (i.e., bugs in JIRA, requirements in Confluence) to RDF data using DIO-PP and DIO is done. The green boxes in the figure 13 below highlight the elements in the Confluence installations that are used in the extraction and conversion process, alongside the respective property or type.

21

Commercial issue-tracker software, see https://www.atlassian.com/software/jira 22

http://unifiedviews-web.semantic-web.at/



Figure 12: Sample Confulence Requirements Page Conversion to DIOPP

The example Turtle RDF snippet provided below illustrates what the extracted data may look like.

swc:dr001 a dio:DesignRequirement; rdfs:comment "This is a requirement highlighting the extended SKOS-XL

functionality"; dc:title "Extended SKOS-XL functionality"^^xsd:string; dc:description "TPCi provides translation list (source glossary).", "Client provides translations.", "Client details meta information about each translation

in the list."; dio:addressedBy swc:di002, swc:di003; prov:wasAttributedTo swc:agent001; dio:wasAssociatedWith swc:agent002, swc:agent003, swc:agent004; dio:qualifiedAssociation [

a prov:Association; prov:agent swc:agent002; prov:hadRole swc:Customer; rdfs:comment "Phase 3"@en

]; dio:qualifiedAssociation [

a prov:Association; prov:agent swc:agent003; prov:hadRole swc:PM;

]; dio:qualifiedAssociation [

a prov:Association;



prov:agent swc:agent004; prov:hadRole swc:Development;

]; prov:generatedAtTime "2015-11-11T13:35:23Z"^^xsd:dateTime; dio:identifies swc:POOL-4924; dio:identifies swc:POOL-4925 . swc:di002 a dio:DesignIntent; dc:title "Improve display of SKOS-XL labels in the Concept Details tabs

(Prio 1)"; dc:description "As a user i want to have all information for a SKOS-XL

label available also in the Concept Details tab so i do not need to switch to the SKOS-XL labels details."; dio:generatesIssue swc:POOL-4935 ; dio:generatesIssue swc:POOL-4973 ; dio:generatesIssue swc:POOL-4982 ; dio:generatesIssue swc:POOL-4967 ; dio:captureMethodology swc:GRIPS . swc:POOL-4935 a dio:DesignIssue ; dio:hasAlternativeSolution swc:sol001 ; diopp:belongsTo dsp001; dio:generatedByIntent di002; dio:version "5.3.2"; dc:title "Drag & drop for SKOS-XL labels in Concept Details"; prov:wasAttributedTo swc:agent005; prov:generatedAtTime "2015-11-11T13:35:23Z"^^xsd:dateTime; diopp:updateDate "2015-11-13T13:35:23Z"^^xsd:dateTime; diopp:dueDate "2015-11-15T13:35:23Z"^^xsd:dateTime; dio:hasStatus swc:open; diopp:hasPriorityType diopp:Major; diopp:isOfIssueType swc:story; diopp:hasReporter swc:agent005; diopp:hasAssignee swc:agent005; diopp:hasResolutionType swc:unresolved; diopp:hasAffectedComponent swc:comp001; dio:hasSubIssues: swc:P00L-4936, swc:P00L-49367.

11 Next Steps

This deliverable defines the interfaces and information exchange formats for the ALIGNED phase 2 demonstrators (D5.5 Integrated ALIGNED Tools). Each of the phase 2 tool releases has requirements set by the ALIGNED metamodel specifications:

D3.2 Model Catalogue – consume OWL domain models, support data lifecycle schema publication lifecycle data

D3.3 Semantic Booster – support Booster software-generation lifecycle in SLO/SIP

D3.4 Model Mapping Tool – write PROV-based tool activity logs using Data Lifecycle/DBpedia vocabularies

D4.3 System Integrity Enforcement Framework – generate unified data integrity validation report, Define system integrity check/enforcement/triplestore write activities

D4.4 Data Testing Framework – produce provenance metadata for validation reports. Produce unified quality report for constraint violation & data quality dimensions



D4.5 Model Generated Data Curation Interfaces & Tools – produce PROV-based records of usage of interfaces and tools, produce RVO-based constraint violation reports in response to errors in input data

D5.2 Unified Governance Tools – consume DIO linked data, consume DIOPP linked data, and extract software engineering process data from JIRA (bugs) and Confluence (requirements) in DIOPP

D5.3 Expert Curation Process & Workflow Tools – produce PROV-based records of workflows & expert interventions based on ERES ontology

D5.4 Test Case Linking – consume and generate unified quality reports and test-case links

This metamodel will be iterated on in project month 24 as D2.8 for phase 3 of the project. Version 3 will extend the deliverable by providing richer metamodels and advanced ontologies based on the feedback of the phase 2 trials, and prototyping experiences derived from developing the phase 2 tool releases.

The ALIGNED project website23 will act as a centralised hub of documentation, ontology/vocabulary specifications and metadata for the software and data engineering metamodel.

12 References

[1] T. Lebo, S. Sahoo, D. McGuinness, PROV-O: The PROV Ontology, W3C Recommendation 30 April 2013, available at: https://www.w3.org/TR/prov-o/

[2] D. Kontokostas, M. Brümmer, C. Dirschl, B. Božić, R. Brennan. D7.11 Data Management Plan Phase 2. ALIGNED project deliverable. January 2016.

[3] A. Koller, H. Nagy, C. Mader, R. David, K. Feeney, D. Kontokostas, R. Brennan. D2.5 Use Cases and Requirements Phase 2. ALIGNED project deliverable. Dec 2015.

[4] M. Solanki, DIO: A pattern for capturing the intents underlying designs. In ISWC 2015 Workshop on Ontology Patterns at ISWC2015.

[5] ISO/IEC 12207:2008, Systems and software engineering -- Software life cycle processes. 2013. Available at: http://www.iso.org/iso/catalogue_detail?csnumber=43447

[6] S. Auer, L. Bühmann, C. Dirschl, O. Erling, M. Hausenblas, R. Isele, J. Lehmann, M. Martin, P. Mendes, B. van Nuffelen, C. Stadler, S. Tramp, H. Williams, Managing the Life-Cycle of Linked Data with the LOD2 Stack, Proc. ISWC 2012, LNCS, Springer Berlin Heidelberg, 2012.

[7] H. Knublauch, A. Ryman, Shapes Constraint Language (SHACL), W3C Working Draft 28 January 2016. Available at: https://www.w3.org/TR/shacl/

[8] R. Albertoni, A. Isaac and C. Gueret, Data on the Web Best Practices: Data Quality Vocabulary, W3C Working Draft 17 December 2015, available at: https://www.w3.org/TR/vocab-dqv/

[9] D. Kontokostas, M. Brummer, S. Hellmann, J. Lehmann, and L. Ioannidis, NLP Data Cleansing Based on Linguistic Ontology Constraints, ESWC 2014. Available at: http://jens-lehmann.org/files/2014/eswc_rdfunit_nlp.pdf

23

http://aligned-project.eu/data-and-models/

https://www.w3.org/TR/shacl/

https://www.w3.org/TR/vocab-dqv/



Appendices

The following appendices provide the full documentation of the ALIGNED Metamodel vocabularies generated by the LODE (Live OWL Documentation Environment) tool (http://www.essepuntato.it/lode/).

The vocabularies are presented in the following order: 1. The Design Intent Ontology, DIO

2. The Software Lifecycle Ontology, SLO

3. The Software Implementation Process Ontology, SIP

4. The Data Lifecycle Ontology, DLO

5. DataID

6. The Reasoning Violation Ontology, RVO

7. Enterprise Information Processing (JURION)

8. E-Research in Social Sciences and Humanities (Seshat)

9. Crowd-sourced Public Datasets (DBpedia)

10. Enterprise Software Development (DIO applied to PoolParty)

http://www.essepuntato.it/lode/

The Design Intent Ontology - A content ontology design pattern

IRI:

https://w3id.org/dio#

Date:

04-01-2016

Current version:

1.1.000

Authors:

Monika Solanki ([email protected])

Imported Ontologies:

http://aligned.cs.ox.ac.uk/ontologies/prov_dio (visualise it with LODE)

Other visualisation:

Ontology source

Table of Content

Introduction1.

Classes2.

Object Properties3.

Data Properties4.

Named Individuals5.

Namespace Declarations6.

Introduction

The Design Intent Ontology (DIO) is a generic ontology that provides the conceptualisation needed to capture

the knowledge generated during various phases of the overall design lifecycle.

It provides definitions for design artifacts such as requirements, designs, design issues, solutions, justifications

and evidence and relationships between them to represent the design process and how these things lead to

design outcomes. It draws upon the paradigms of IBIS(Interactive Intent-Based Illustration), argumentation and

design rationale. It is linked to W3C PROV by defining the actors in the design process as PROV agents and

the design artifacts themselves are PROV entities. However DIO uses a modualrised version of PROV-O,

based on Syntactic locality.

DIO makes few assumptions about the design process used as the definitions of these activities properly

belongs in the software lifecycle and data lifecycle models. The Figure below illustrates the conceptual entities

in DIO and their relationships.

back to ToC or Class ToC


Classes

Alternative Solution Argument Assumption Comment Constraint Design Design Decision

Design Goal Design Intent Design Intent Artifact Design Issue Design Requirements Evaluation

Evidence Heuristic Justification Mandated Solution Rationale Capture Methodology Solution

Status

Alternative Solutionc

IRI: https://w3id.org/dio#AlternativeSolution

An entity representing the proposed solution.

has super-classes

Solutionc

is in range of

hasAlternativeSolutionop

Argumentc

IRI: https://w3id.org/dio#Argument

A reason presented against a proposed solution.

has super-classes

Design Intent Artifactc

is in domain of

hasEvidenceop

is in range of

hasArgumentop, supportsop







Assumptionc

IRI: https://w3id.org/dio#Assumption

The assumption on which a proposed solution is based.

has super-classes


is in range of

usesAssumptionop

Commentc

IRI: https://w3id.org/dio#Comment

A comment made by an agent in response to an argument, a justification or another comment

has super-classes


Constraintc

IRI: https://w3id.org/dio#Constraint

A constraint that underlies the proposed solution.

has super-classes


is in range of

hasConstraintop

Designc

IRI: https://w3id.org/dio#Design

A design is a specification of an object, manifested by an agent, intended to accomplish goals, in a particular

environment, using a set of components, satisfying a set of requirements, subject to constraints.

is in domain of

fullfillsRequirementsop

is in range of

governsDesignop

Design Decisionc

IRI: https://w3id.org/dio#DesignDecision

The final design decision made based on the various alternative solutions proposed. A design decision is

driven by a mandated solution.

is in domain of

governsDesignop

is in range of

leadsToop

Design Goalc

IRI: https://w3id.org/dio#DesignGoal






An entity representing the problem, goal, question or issue the design intent aims to address.

is equivalent to

Design Issuec

has super-classes

Design Intent Artifactc and (hasAlternativeSolutionop only Alternative Solutionc) and

(hasMandatedSolutionop only Mandated Solutionc) and (hasMandatedSolutionop max 1 Mandated

Solutionc)

Design Intentc

IRI: https://w3id.org/dio#DesignIntent

A entity defining the notion of a design intent, i.e., the rationale underpinning the choices that are made from

the alternatives available during various phases of the overall design lifecycle.

has super-classes



IRI: https://w3id.org/dio#DesignIntentArtifact

An entity representing any artifact that plays a part in capturing the design intent. The minimum ontological

commitment required for this entity is a brief description of the artifact, the version info and the date.

has super-classes

(was attributed toop exactly 1 agent) and (generated at timedp exactly 1) and (versiondp exactly 1)

has sub-classes

Argumentc, Assumptionc, Commentc, Constraintc, Design Intentc, Design Issuec, Design

Requirementsc, Evaluationc, Evidencec, Heuristicc, Justificationc, Solutionc

is in domain of


Design Issuec

IRI: https://w3id.org/dio#DesignIssue

An entity representing the problem, goal, question or issue the design intent aims to address.

has super-classes


is in domain of

hasStatusop

Design Requirementsc

IRI: https://w3id.org/dio#DesignRequirement

An entity capturing the requirements that result in the design intent

has super-classes


is in range of


Evaluationc






IRI: https://w3id.org/dio#Evaluation

An entity representing the evaluation that supports the solution.

has super-classes


Evidencec

IRI: https://w3id.org/dio#Evidence

An entity representing an evidence that supports a proposed solution.

has super-classes


is in range of

hasEvidenceop

Heuristicc

IRI: https://w3id.org/dio#Heuristic

An entity representing the requirements to be fulfilled for realising the solution

has super-classes


is in range of

usesHeuristicop

Justificationc

IRI: https://w3id.org/dio#Justification

A reason supporting the proposed solution.

has super-classes


is in domain of

hasEvidenceop

is in range of

hasJustificationop, supportsop

Mandated Solutionc

IRI: https://w3id.org/dio#MandatedSolution

An entity representing the solution accepted as a result of the design deliberation process.

has super-classes

Solutionc

is in domain of

leadsToop

is in range of

hasMandatedSolutionop

Rationale Capture Methodologyc

IRI: https://w3id.org/dio#RationaleCaptureMethod



back to ToC or Object Property ToC



An entity representing the methodology used to capture the design intent artifact

Solutionc

IRI: https://w3id.org/dio#Solution

has super-classes


has sub-classes

Alternative Solutionc, Mandated Solutionc

is in domain of

contradictsop, hasConstraintop, refinesop, usesAssumptionop, usesHeuristicop

is in range of

contradictsop, refinesop

Statusc

IRI: https://w3id.org/dio#Status

An entity representing the status of a design issue.

is in range of

hasStatusop

has members

Activeni, onHoldni, resolvedni, terminatedni

Object Properties

addressedBy captureMethodology contradicts fullfillsRequirements generatedByIntent

generatesIssue governsDesign hasAlternativeSolution hasArgument hasComment

hasConstraint hasEvidence hasJustification hasMandatedSolution hasStatus

identifiedByRequirement identifies leadsTo providesAlternativeSolution

providesMandatedSolution rationaleCapturedUsing refines requirementFulfilledBy supports

usesAssumption usesHeuristic

addressedByop

IRI: https://w3id.org/dio#addressedBy

A relationship stating the design intent addressing a requirement.

captureMethodologyop

IRI: https://w3id.org/dio#captureMethodology

A relationship identifying the capture methodology for a design issue

contradictsop

IRI: https://w3id.org/dio#contradicts

A relationship indicating contradictory issues.

has domain

Solutionc






has range

Solutionc


IRI: https://w3id.org/dio#fulfillsRequirement

A relationship between the design and its requirement.

has domain

Designc


has range

Design Requirementsc

is inverse of

requirementFulfilledByop

generatedByIntentop

IRI: https://w3id.org/dio#generatedByIntent

A relationship between the design issue and intent.

is inverse of

generatesIssueop

generatesIssueop

IRI: https://w3id.org/dio#generatesIssue

A relationship between the design intent and issue.

is inverse of

generatedByIntentop

governsDesignop

IRI: https://w3id.org/dio#governsDesign

The design decision governing the design.

has domain

Design Decisionc

has range

Designc


IRI: https://w3id.org/dio#hasAlternativeSolution

The realtionship between the issue and an alternative solution for it.

has super-properties

top object property

has range

Alternative Solutionc

is inverse of

providesAlternativeSolutionop







hasArgumentop

IRI: https://w3id.org/dio#hasArgument

The relationship between a solution and an argument made against it.

has range

Argumentc

hasCommentop

IRI: https://w3id.org/dio#hasComment

The relationship between a comment and a design intent artifact for which the comment is made.

hasConstraintop

IRI: https://w3id.org/dio#hasConstraint

A relationship between a solution and a constarint on it.

has domain

Solutionc

has range

Constraintc

hasEvidenceop

IRI: https://w3id.org/dio#hasEvidence

A relationship between a solution and an evidence for it.

has domain

Argumentc

Justificationc

has range

Evidencec

hasJustificationop

IRI: https://w3id.org/dio#hasJustification

A relationship between a solution and the justification for it.

has range

Justificationc


IRI: https://w3id.org/dio#hasMandatedSolution

A relationship between the issue and its mandated solution.


top object property

has range

Mandated Solutionc

is inverse of







providesMandatedSolutionop

hasStatusop

IRI: https://w3id.org/dio#hasStatus

The relationship between an issue and its status.

has domain

Design Issuec

has range

Statusc

identifiedByRequirementop

IRI: https://w3id.org/dio#identifiedByRequirement

The relationship between an issue and the requirement that identifies it.

is inverse of

identifiesop

identifiesop

IRI: https://w3id.org/dio#identifies

A relationship between the requirement and the issue it identifies.

is inverse of

identifiedByRequirementop

leadsToop

IRI: https://w3id.org/dio#leadsTo

A relationship between a mandated solution and design decision made based on it.


top object property

has domain

Mandated Solutionc

has range

Design Decisionc

providesAlternativeSolutionop

IRI: https://w3id.org/dio#providesAlternativeSolution

A relationship between an alternative solution and the issue.

is inverse of


providesMandatedSolutionop

IRI: https://w3id.org/dio#providesMandatedSolution

A relationship between a mandated solution and the issue.







is inverse of


rationaleCapturedUsingop

IRI: https://w3id.org/dio#rationaleCapturedUsing

A relationship between the design rationale and its capture methodology.

refinesop

IRI: https://w3id.org/dio#refines

A relationship between two requirememts when one refines the other.

has domain

Solutionc

has range

Solutionc

requirementFulfilledByop

IRI: https://w3id.org/dio#requirementFulfilledBy

A relationship between the design and its originating requirements

is inverse of


supportsop

IRI: https://w3id.org/dio#supports

A relationship between an agent and a design solution argument or justification.

has range

Argumentc

Justificationc

usesAssumptionop

IRI: https://w3id.org/dio#usesAssumption

A relationship between a solution and the Assumption it makes.

has domain

Solutionc

has range

Assumptionc

usesHeuristicop

IRI: https://w3id.org/dio#usesHeuristic

A relationship between a solution and the heuristic iy uses.

has domain

Solutionc

back to ToC or Data Property ToC

back to ToC or Named Individual ToC




back to ToC

has range

Heuristicc

Data Properties

version

versiondp

IRI: https://w3id.org/dio#version

Named Individuals

Active onHold resolved terminated

Activeni

IRI: https://w3id.org/dio#Active

The status of an issue when it is active.

belongs to

Statusc

onHoldni

IRI: https://w3id.org/dio#OnHold

The status of an issue when it is onHold

belongs to

Statusc

resolvedni

IRI: https://w3id.org/dio#Resolved

The status of an issue when it is resolved.

belongs to

Statusc

terminatedni

IRI: https://w3id.org/dio#Terminated

The status of an issue when it is terminated.

belongs to

Statusc

Namespace Declarations

default namespace

https://w3id.org/dio

dc

http://purl.org/dc/elements/1.1/

dio


images

http://aligned.cs.ox.ac.uk/images/

ontologies

http://aligned.cs.ox.ac.uk/ontologies/

owlhttp://www.w3.org/2002/07/owl#

prov

http://www.w3.org/ns/prov#

rdf

http://www.w3.org/1999/02/22-rdf-syntax-ns#

rdfs

http://www.w3.org/2000/01/rdf-schema#

xsd

http://www.w3.org/2001/XMLSchema#

This HTML document was obtained by processing the OWL ontology source code through LODE, Live OWL Documentation Environment, developed by Silvio

Peroni.

The Software Lifecycle Ontology

IRI:

http://aligned.cs.ox.ac.uk/ontologies/slo

Date:

30-06-2015

Current version:

1.0.000

Authors:

Monika Solanki (monika.solanki


http://www.ontologydesignpatterns.org/ont/dul/DUL.owl (visualise it with LODE)

http://www.w3.org/ns/prov-o# (visualise it with LODE)


Ontology source

This vocabulary is licensed under a Creative Commons Attribution License - http://creativecommons.org

/licenses/by/3.0

Table of Content

Introduction1.

Classes2.

Object Properties3.

Data Properties4.


Introduction

The Software Lifecycle Ontology (SLO) is the top level ontology for describing a process in the lifecycle of a

Software.

The ontology conforms to the ISO/IEC 12207 standard for Systems and software engineering — Software life

cycle processes. The terminology used in the ontology conforms to ISO/IEC TR 24774:2010(E). All

subprocesses will require to import this module.

The figure below illustrates the conceptual entities in SLO. The core concept is a SoftwareLifecyleProcess

which can be decomposed into sub-processes, tasks and activities. The SIP ontology builds on this basic

framework to describe standard software engineering processes e.g. requirements analysis and architectural

design.



Classes

Activity Information Item Process Outcome Software Lifecycle Process Task

Activityc

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#Activity

Activities describe a set of actions that might be undertaken to execute the process. Activities are constructs

for grouping together related tasks. The activities provide a means to look at related tasks within the process

to improve understanding and communication of the process.

has super-classes

action

activity

is in domain of

has taskop

Information Itemc

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#InformationItem

Information items are process products that are of particular interest to life cycle management. Information

items are separately identifiable bodies of information that are produced and stored for human use during a

system or software life cycle. In other words they are the outputs from and inputs to system and software life

cycle processes and are transformed by these processes.

has super-classes

information entity

is in range of






has information itemop

Process Outcomec

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#ProcessOutcome

Observable result of the successful achievement of the process purpose

Software Lifecycle Processc

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#SoftwareLifecycleProcess

The generic software lifecycle process. It is a specialisation of the Process entity from the DUL ontology.

ISO:12207: set of interrelated or interacting activities which transforms inputs into outputs

has super-classes

process

is in domain of

has activityop, has information itemop

Taskc

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#Task

Tasks are written to define specific requirements, or provide recommendations on the execution of a

conforming process.

A task is expressed in the form of a requirement, recommendation, or permissible action, intended to support

the achievement of the outcomes of a process.

has super-classes

action

Object Properties

has activity has information item has outcome has task

has activityop

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#hasActivity

A relationship between the Software Lifecycle Process and the activities it incorporates.


has component

has domain


has range

activity

has information itemop

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#hasInformationItem

A relationship between the Software Lifecycle Process and the information item defined for it.





back to ToC


has component

has domain


has range

Information Itemc

has outcomeop

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#hasOutcome

A relationship between the process and its outcome.

has taskop

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#hasTask

A relationship between the task and the activity it is associated with.


associated with

has component

has domain

Activityc

has range

task

Data Properties

has Purpose has Title

has Purposedp

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#hasPurpose

The purpose of the process is stated as a high level, overall goal for performing the process. In cases where

processes might be thought to overlap, the purpose should be used to characterize the scope or bounds of

the process. Whenever possible, the purpose should be succinctly captured in a single sentence.

has Titledp

IRI: http://aligned.cs.ox.ac.uk/ontologies/slo#hasTitle

The title of a process description is a short noun phrase that presents a descriptive heading for the process.

The title identifies the principle concern of the process and distinguishes the process from other processes in

the model.


default namespace

http://aligned.cs.ox.ac.uk/ontologies/slo#

dc


dul

http://www.ontologydesignpatterns.org/ont/dul/

dul-owl

http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#

images


ontologies


owl

http://www.w3.org/2002/07/owl#

prov


rdf


rdfs


xsd



Peroni.

The Software Implementation Process ontology

IRI:

http://aligned.cs.ox.ac.uk/ontologies/sip#

Date:

05-07-2015

Current version:

1.0.000

Authors:

Monika Solanki


http://aligned.cs.ox.ac.uk/ontologies/slo (visualise it with LODE)

http://protege.stanford.edu/plugins/owl/dc/protege-dc.owl (visualise it with LODE)

http://purl.obolibrary.org/obo/swo.owl (visualise it with LODE)

http://www.ontologydesignpatterns.org/ont/dul/DUL.owl (visualise it with LODE)

http://www.w3.org/ns/prov-o# (visualise it with LODE)


Ontology source

This vocabulary is licensed under a Creative Commons Attribution License - http://creativecommons.org

/licenses/by/3.0

Table of Content

Introduction1.

Classes2.


Introduction

The purpose of the Software Implementation Process ontology is to provide a set of conceptual entities to

represent a specified system element implemented as a software product or service.

This ontology imports the Software Lifecycle Ontology (SLO) available at http://aligned.cs.ox.ac.uk/ontologies

/slo#. It also utilises concepts defined in the SEON ontologies available at http://www.se-on.org/ and the

Software ontology (SWO) available at http://purl.obolibrary.org/obo/swo.owl. Agents using this ontology are

strongly recommended to exploit the various terms and relationships defined within SWO and SEON for

asserting the requirements of their implementation processes.

The basic concepts of the SIP ontology are illustrated in the figure below. It shows the definition of basic

software engineering processes and activities such as requirements analysis, design, implementation,





Classes

Software architectural design Software Architectural Design Process Software construction

Software Construction Process Software detailed design Software Detailed Design Process

Software Implementation Process Software implementation strategy Software integration

Software Integration Process Software Qualification Testing Process Software requirements analysis

Software Requirements Analysis Process

Software architectural designc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareArchitecturalDesign

has super-classes

activity

Software Architectural Design Processc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareArchitecturalDesignProcess

The purpose of Software Requirements Analysis Process is to establish the requirements of the software

elements of the system.

has super-classes

Software Implementation Processc and (has activity some Software architectural designc)

Software constructionc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareConstruction

has super-classes

activity

Software Construction Processc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareConstructionProcess

The purpose of the Software Construction Process is to produce executable software units that properly







reflect the software design.

has super-classes

Software Implementation Processc and (has activity some Software constructionc)

Software detailed designc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareDetailedDesign

has super-classes

activity

Software Detailed Design Processc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareDetailedDesignProcess

The purpose of the Software Detailed Design Process is to provide a design for the software that implements

and can be verified against the requirements and the software architecture and is sufficiently detailed to

permit coding and testing

has super-classes

Software Implementation Processc and (has activity some Software detailed designc)

Software Implementation Processc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareImplementationProcess

This process transforms specified behaviour, interfaces and implementation constraints into actions that

create a system element impl emented as a software product or service, otherwise known as a "software

item." This process results in a software item that satisfies architectural design requirements through

verification and stakeholder requirements through validation.

has super-classes

software lifecycle process and (has activity some Software Implementation Processc)

has sub-classes

Software Qualification Testing Processc

Software implementation strategyc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareImplementationStrategy

has super-classes

activity

Software integrationc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareIntegration

has super-classes

activity

Software Integration Process c

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareIntegrationProcess

The purpose of the Software Integration Process is to combine the software units and software components,

producing integrated software items, consistent with the software design, that demonstrate that the functional

and non-functional software requirements are satisfied on an equivalent or complete operational platform.




back to ToC

has super-classes

Software Implementation Processc and (has activity some Software integrationc)

Software Qualification Testing Processc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareQualificationTestingProcess

has super-classes

Software Implementation Processc

The purpose of the Software Qualification Testing Process is to confirm that the integrated software product

meets its defined requirements.

Software requirements analysisc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareRequirementsAnalysis

has super-classes

activity

Software Requirements Analysis Processc

IRI: http://aligned.cs.ox.ac.uk/ontologies/sip#SoftwareRequirementsAnalysisProcess

The purpose of Software Requirements Analysis Process is to establish the requirements of the software

elements of the system.

has super-classes

Software Implementation Processc and (has activity some Software requirements analysisc)


default namespace

http://aligned.cs.ox.ac.uk/ontologies/sip#

dc


dul

http://www.ontologydesignpatterns.org/ont/dul/

images


obo

http://purl.obolibrary.org/obo/

ontologies


owl


rdf


rdfs


slo


xsd



Peroni.

Data Lifecycle Ontology

IRI:

http://aligned-project.eu/ontologies/dlo

Date:

11-02-2015

Current version:

2.12.000

Authors:

Bojan Božić ([email protected])

Contributors:

Kevin C. Feeney ([email protected])

Rob Brennan ([email protected])

Publisher:



http://protege.stanford.edu/plugins/owl/dc/protege-dc.owl (visualise it with LODE)

http://www.w3.org/ns/dcat (visualise it with LODE)

http://www.w3.org/ns/prov-o-20130430 (visualise it with LODE)


Ontology source

Abstract

This ontology provides a description of the data lifecycle for Linked Data.

It captures various processes involved in the lifecycle of data and answeres the following questions:

What lifecycle stage is a specific dataset or data item currently in?

What is the next lifecycle stage for a particular data item (workflows)?

What is the appropriate widget or form to display this data item in for a specific user role, given the data

item’s state (lifecycle stage)?

What is the context for a specific data item (dataset name/URI/meta-data URI, PROV records, …)?

Which agents, processes, and entities are involved in a lifecycle run?

Table of Content

Introduction1.

Classes2.

Object Properties3.


Introduction

The purpose of the Data Lifecycle Ontology is to provide a set of conceptual entities, agents, activities, and

roles to represent the general data engineering process. Furthermore, it is the basis for deriving specific

domain ontologies which represent lifecycles of concrete data engineering projects such as DBpedia or

Seshat.

DLO uses the W3C PROV ontology represented by the classes Role, Person, Entity, and Activity. It uses the

Process class which is derived from Activity to implement the Linked Data Stack lifecycle stages as

subclasses. This allows the user to represent linked open data activities in the data lifecycle metamodel. In

addition datasets, data sources and data repositories have been modelled. For datasets it imports the W3C

Data Catalog Vocabulary (DCAT) definition of a dataset as it is a broad definition that goes beyond




representing only RDF-based datasets.

The W3C PROV ontology is available at http://www.w3.org/TR/prov-o/. The concepts defined in the LOD2

project are available at http://stack.lod2.eu/blog/.

Classes

Authoring Classification Data Artifact Data Engineer Data Entity Data Lifecycle Process

Data Process Person Data Software Agent Data Source dataset Domain Expert

Evolution/Repair Extraction Interlinking Quality Analysis Repository

Search/Browsing/Exploration Storage System Administrator Test Case Test Case Result User

Authoringc

IRI: http://aligned-project.eu/ontologies/dlo#Authoring

The LOD2 Stack facilitates the authoring of rich semantic knowledge bases, by leveraging Semantic Wiki

technology, the WYSIWYM paradigm (What You See Is What You Mean) and distributed social, semantic

collaboration and networking techniques.

has super-classes

Data Lifecycle Processc

Classificationc

IRI: http://aligned-project.eu/ontologies/dlo#Classification

Linked Data on the Web is mainly raw instance data. For data integration, fusion, search and many other

applications, however, we need this raw instance data to be classified into taxonomies. In the LOD2 stack,

semi-automatic components for this purpose are included.

has super-classes


Data Artifactc

IRI: http://aligned-project.eu/ontologies/dlo#DataArtifact

An artifact is a process-oriented item such as a design or report used in the data lifecycle.





has super-classes

Data Entityc

has sub-classes

Test Casec, Test Case Resultc

Data Engineerc

IRI: http://aligned-project.eu/ontologies/dlo#DataEngineer

Data engineers are the designers, builders and managers of an information infrastructure. They develop the

architecture that helps analyze and process data in the way the organization needs it. And they make sure

those systems are performing smoothly. Data science is a team sport.

has super-classes

Data Process Personc

Data Entityc

IRI: http://aligned-project.eu/ontologies/dlo#DataEntity

A class for general data entities.

has super-classes

entity

has sub-classes

Data Artifactc, Data Sourcec, Repositoryc, datasetc

is in range of

consumesop, producesop


IRI: http://aligned-project.eu/ontologies/dlo#DataLifecycleProcess

A general class for describing specific steps during the processing of linked data.

has super-classes

activity

has sub-classes

Authoringc, Classificationc, Evolution/Repairc, Extractionc, Interlinkingc, Quality Analysisc,

Search/Browsing/Explorationc, Storagec

is in domain of

consumesop, has sub processop, is supported byop, producesop

is in range of

has sub processop, initiatesop, is responsible forop, supportsop


IRI: http://aligned-project.eu/ontologies/dlo#DataProcessPerson

A person who is involved in the data processing lifecycle.

has super-classes

person

has sub-classes

Data Engineerc, Domain Expertc, System Administratorc, Userc

is in domain of

initiatesop







Data Software Agentc

IRI: http://aligned-project.eu/ontologies/dlo#DataSoftwareAgent

A specific software agent involved in the data lifecycle.

has super-classes

software agent

is in domain of

supportsop

Data Sourcec

IRI: http://aligned-project.eu/ontologies/dlo#DataSource

A data source defines where data comes from.

has super-classes

Data Entityc

datasetc

IRI: http://dataid.dbpedia.org/ns/core#Dataset

has super-classes

Data Entityc

Domain Expertc

IRI: http://aligned-project.eu/ontologies/dlo#DomainExpert

A person who is an authority in a particular area or topic. The term domain expert is frequently used in expert

systems software development, and there the term always refers to the domain other than the software

domain.

has super-classes


Evolution/Repairc

IRI: http://aligned-project.eu/ontologies/dlo#Evolution

Data on the Web is dynamic. We need to facilitate the evolution of data while keeping things stable. Changes

and modifications to knowledge bases, vocabularies and ontologies should be transparent and observable.

The LOD2 Stack comprises methods to spot problems in knowledge bases and to automatically suggest

repair strategies.

has super-classes


Extractionc

IRI: http://aligned-project.eu/ontologies/dlo#Extraction

Gathering data from unstructured, semi-structured, and structured sources.

has super-classes








Interlinkingc

IRI: http://aligned-project.eu/ontologies/dlo#Interlinking

Creating and maintaining links in a (semi-)automated fashion is still a major challenge and crucial for

establishing coherence and facilitating data integration as outlined in the publishing usage scenario in the

introduction. We seek linking approaches yielding high precision and recall, which configure themselves

automatically or with end-user feedback.

has super-classes


Quality Analysisc

IRI: http://aligned-project.eu/ontologies/dlo#QualityAnalysis

The quality of content on the Data Web varies, as the quality of content on the document web varies. The

LOD2 Stack comprises techniques for assessing quality based on characteristics such as provenance,

context, coverage or structure. The goal in our application scenarios is to assess whether data sources for a

publisher are complete, consistent, reliable etc.

has super-classes


Repositoryc

IRI: http://aligned-project.eu/ontologies/dlo#Repository

A central location in which data is stored and managed.

has super-classes

Data Entityc

is in domain of

storesop

Search/Browsing/Explorationc

IRI: http://aligned-project.eu/ontologies/dlo#Search

For many users, the Data Web is still invisible below the surface. LOD2 develops search, browsing,

exploration and visualization techniques for different kinds of Linked Data (i.e. spatial, temporal, statistical),

which make the Data Web sensible for real users.

has super-classes


Storagec

IRI: http://aligned-project.eu/ontologies/dlo#Storage

Efficient RDF data management techniques fulfilling requirements of global publishers comprise column-store

technology, dynamic query optimization, adaptive caching of joins, optimized graph processing and

cluster/cloud scalability.

has super-classes


System Administratorc






IRI: http://aligned-project.eu/ontologies/dlo#SystemAdministrator

A person who is responsible for managing the data engineering system.

has super-classes


Test Casec

IRI: http://aligned-project.eu/ontologies/dlo#TestCase

A data test case description.

has super-classes

Data Artifactc

Test Case Resultc

IRI: http://aligned-project.eu/ontologies/dlo#TestCaseResult

A data test case result or report.

has super-classes

Data Artifactc

Userc

IRI: http://aligned-project.eu/ontologies/dlo#User

A person who is using the data engineering system.

has super-classes


Object Properties

consumes has sub process initiates is responsible for is supported by produces stores

supports

consumesop

IRI: http://aligned-project.eu/ontologies/dlo#consumes

has domain


has range

Data Entityc

is inverse of

was attributed to

has sub processop

IRI: http://aligned-project.eu/ontologies/dlo#hasSubProcess

has domain


has range








initiatesop

IRI: http://aligned-project.eu/ontologies/dlo#initiates

has domain


has range


is responsible forop

IRI: http://aligned-project.eu/ontologies/dlo#isResponsibleFor

has domain

person

has range


is supported byop

IRI: http://aligned-project.eu/ontologies/dlo#isSupportedBy


was associated with

has domain


has range

software agent

producesop

IRI: http://aligned-project.eu/ontologies/dlo#produces


generated

has domain


has range

Data Entityc

storesop

IRI: http://aligned-project.eu/ontologies/dlo#stores

has domain

Repositoryc

has range

distributionc

supportsop

IRI: http://aligned-project.eu/ontologies/dlo#supports

has domain

back to ToC

Data Software Agentc

has range



default namespace

http://aligned-project.eu/ontologies/dlo#

core

http://dataid.dbpedia.org/ns/core#

dc


images

https://www.scss.tcd.ie/~bozicb/images/

ns

http://www.w3.org/ns/

ontologies

http://aligned-project.eu/ontologies/

owl


prov


rdf


rdfs


terms

http://purl.org/dc/terms/

xsd



Peroni.



DataID

IRI:


Current version:

1.0.0


http://vocab.deri.ie/void (visualise it with LODE)

http://www.w3.org/ns/dcat (visualise it with LODE)

http://www.w3.org/ns/prov (visualise it with LODE)


Ontology source

Abstract

DBpedia Data ID is an ontology with the goal of describing LOD datasets via RDF files in a uniform way.

Established vocabularies like DCAT, VoID, Prov-O and SPARQL Service Description are used for maximum

compatibility.

Table of Content

Classes1.

Object Properties2.

Data Properties3.


Classes

Access level Agent agent identifier Agent role Authority entity context Authorized action

DataId Dataset dataset files in differnt paths of a distribution dataset files in one directory

Distribution Entitled action Linkset responsible actions Service Endpoint single dump file

Sparql Endpoint

Access levelc

IRI: http://dataid.dbpedia.org/ns/core#AccessLevel

is defined by


The level of openness of access to particular groups of agents

is equivalent to

{ }

is in range of

access levelop, valid for access levelop

Agentc

IRI: http://dataid.dbpedia.org/ns/core#Agent

is defined by


Any type of agent without a specific function.




is equivalent to

has super-classes

agent

agent

account max 1

name exactly 1

is in range of

associated agentop, authorized agentop

agent identifierc

IRI: http://dataid.dbpedia.org/ns/core#AgentIdentifier

is defined by


Uniquly identifies an agent given a identifier and a correspondng aid/pid system (ORCID, ResearcherID etc.).

has super-classes

aiddp exactly 1

aid systemdp exactly 1

Agent rolec

IRI: http://dataid.dbpedia.org/ns/core#AgentRole

is defined by


Instances of this class define an array of rights and responsibilities an agent, assigned with this role for a

given scope of entities, has to address or can execute.

is equivalent to

{ }

has super-classes

allowes forop min 1

is in domain of

allowes forop

is in range of

authority agent roleop

Authority entity contextc

IRI: http://dataid.dbpedia.org/ns/core#AuthorityEntityContext

is defined by


This concept defines a scope of Entities and links it to an Agent which has certain rights for those entities

(defined by the AgentRole). This scope consists of all Entities directly linked to the context, as well as

transitively dependend Entities

has super-classes

authorized forop min 1

authority agent roleop exactly 1

authorized agentop exactly 1

is inheritabledp exactly 1

valid fromdp max 1

valid untildp max 1

is in domain of

authority agent roleop, authorized agentop, authorized forop, is inheritabledp, valid for access levelop,

valid fromdp, valid untildp




Authorized actionc

IRI: http://dataid.dbpedia.org/ns/core#AuthorizedAction

is defined by


AgentRoles provide agents with the ability to execute certain actions as well as demand certain

responsibilities, which are defines by the instances of this concept.

is equivalent to

has sub-classes

Entitled actionc, responsible actionsc

is in range of

allowes forop

DataIdc

IRI: http://dataid.dbpedia.org/ns/core#DataId

is defined by


A description of one or more datasets. The DataID itself.

has super-classesdataset description

catalog record

entity

has version exactly 1

issued exactly 1

latest linkset versionop only DataIdc

next versionop only DataIdc

previous versionop only DataIdc

modified exactly 1

next versionop max 1 Datasetc

versiondp max 1

latest linkset versionop max 1 Datasetc

previous versionop max 1 Datasetc

associated agentop exactly 1

primary topic only Datasetc

Datasetc

IRI: http://dataid.dbpedia.org/ns/core#Dataset

is defined byhttp://dataid.dbpedia.org/ns/core#

A collection of data, available for access in one or more formats. Dataset resources describe the concept of

the dataset, not it's manifestation (the data itself), which can be acquired as Distribution. Datasets are

prov:Entities and can be generated by prov:Activities.

has super-classes

dataset

dataset

entity

latest linkset versionop only Datasetc

next versionop only Datasetc

previous versionop only Datasetc

versiondp max 1

vocabulary max 1

label max 1

entities max 1

classes max 1




description max 1

distinct objects max 1

rights max 1

title exactly 1

accrual periodicity max 1

language only language

language max 1 language

next versionop max 1

root resource max 1

license exactly 1 policy

license only policy

distribution only Distributionc

keyword min 1

associated agentop min 1

triples max 1

documents max 1

subset only Datasetc

landing page min 1

issued max 1

latest linkset versionop max 1

previous versionop max 1

properties max 1

modified max 1

distinct subjects max 1

is in domain of

contains linksop, similar dataop

is in range of

Is distribution ofop, similar dataop

dataset files in differnt paths of a distributionc

IRI: http://dataid.dbpedia.org/ns/core#FileCollection

is defined by


Multiple files of a distribution constituting one dataset.

has super-classes

Distributionc

checksumdp max 1

download u r l min 1

dataset files in one directoryc

IRI: http://dataid.dbpedia.org/ns/core#Directory

is defined by


A dedicated directory holding multiple files of the same dataset.

has super-classes

Distributionc

checksumdp max 1

access u r l min 1

Distributionc

IRI: http://dataid.dbpedia.org/ns/core#Distribution


A way to access a dataset, like a dump file, an endpoint, an API etc.



is equivalent to

has super-classes

distribution

entity

latest linkset versionop only Distributionc

next versionop only Distributionc

previous versionop only Distributionc

versiondp max 1

title max 1

rights max 1

license exactly 1 policy

license only policy

format exactly 1

access u r l max 1

label max 1

media type max 1

byte size max 1

description max 1

Graph namedp max 1

issued max 1

modified max 1

has sub-classes

Service Endpointc, Sparql Endpointc, dataset files in differnt paths of a distributionc, dataset files in one

directoryc, single dump filec

is in domain of

Graph namedp, Is distribution ofop, access proceduredp, data previewop, software requirementop

Entitled actionc

IRI: http://dataid.dbpedia.org/ns/core#EntitledAction

is defined by


AgentRoles provide access and modification rights to an agent. Entitled actions should comprise actions

pertaining to access/modification restrictions.

is equivalent to

{ }

has super-classes

Authorized actionc

Linksetc

IRI: http://dataid.dbpedia.org/ns/core#Linkset

is defined by


Entity representing the set of links between two datasets.

has super-classes

linkset

entity

latest linkset versionop only Linksetc

next versionop only Linksetc

previous versionop only Linksetc

versiondp max 1

has version exactly 1

objects target exactly 1 dataset

subjects target exactly 1 dataset

triples max 1

example resource max 1

previous versionop max 1 Linksetc





modified max 1

latest linkset versionop max 1 Linksetc

next versionop max 1 Linksetc

is in range of

contains linksop

responsible actionsc

IRI: http://dataid.dbpedia.org/ns/core#ResponsibleAction


AgentRoles provide access rights as well as responsibilities an agent has to attend to in order to fullfill this

role. Responsible actions should describe actions pertaining to responsibilities an agent is supposed to do.

is equivalent to

{ }

has super-classes

Authorized actionc

Service Endpointc

IRI: http://dataid.dbpedia.org/ns/core#ServiceEndpoint

is defined by


A specific distribution, which is accessible via an access url and provides data as a web service in a certain

format.

has super-classes

Distributionc

service

access u r l min 1

single dump filec

IRI: http://dataid.dbpedia.org/ns/core#SingleFile

is defined by


A single data dump file representing your dataset.

has super-classes

Distributionc

checksumdp max 1

download u r l exactly 1

Sparql Endpointc

IRI: http://dataid.dbpedia.org/ns/core#SparqlEndpoint

is defined by


A specific distribution, which is accessible via an access url and can be queried with the SPARQL language.

has super-classes

Distributionc

service

access u r l min 1

Object Properties






access level allowes for associated agent authority agent role authorized agent authorized for

contains links data preview has authority-entity-context Is distribution of latest linkset version

next version previous version similar data software requirement valid for access level

access levelop

IRI: http://dataid.dbpedia.org/ns/core#hasAccessLevel

is defined by


defines the access rights for DataId related entities

has characteristics: functional

has domain

entity

has range

Access levelc

allowes forop

IRI: http://dataid.dbpedia.org/ns/core#allowsFor

is defined by


AgentRoles allows an agent to execute certain actions.

has domain

Agent rolec

has range

Authorized actionc

associated agentop

IRI: http://dataid.dbpedia.org/ns/core#associatedAgent

is defined by


some agent generally connected to the dataset, their function to be specified by their rdf:type

has domain

entity

has range

Agentc

authority agent roleop

IRI: http://dataid.dbpedia.org/ns/core#authorityAgentRole

is defined by


Adds a role an agent can administer in the scope provided by the AuthorityEntityContext, thereby allowing for

certain actions an agent can execute.

has domain


has range

Agent rolec

authorized agentop





IRI: http://dataid.dbpedia.org/ns/core#authorizedAgent

is defined by


Provides an agent the ability to execute authorized actions in a certain scope (e.g. to modify the metadata of

a dataset)

has domain


has range

Agentc

authorized forop

IRI: http://dataid.dbpedia.org/ns/core#authorizedFor

is defined by


Defines the scope of an authority-context. An Agent has the right to execute authorized actions in this scope

(e.g. a single DataId and all it's members).

has domain


has range

entity

is inverse of

has authority-entity-contextop

contains linksop

IRI: http://dataid.dbpedia.org/ns/core#containsLinks


Set of links to another dataset contained in this dataset

has domain

Datasetc

has range

Linksetc

data previewop

IRI: http://dataid.dbpedia.org/ns/core#preview

is defined by


provides the uri of a short preview of the data provided by a distribution (do not link to the download or

accessURL with this property)

has domain

Distributionc

has range

document

has authority-entity-contextop

IRI: http://dataid.dbpedia.org/ns/core#hasEntityContext

is defined by


Points out a dataid:AuthorityEntityContext pertaining to this resource.






is inverse of

authorized forop

Is distribution ofop

IRI: http://dataid.dbpedia.org/ns/core#isDistributionOf

is defined by


Inverse property of dcat:distribution, linking a Distribution to a Dataset

has domain

Distributionc

has range

Datasetc

is inverse of

distribution

latest linkset versionop

IRI: http://dataid.dbpedia.org/ns/core#latestVersion


Latest version of a DataIdPart

has domainentity

has range

entity

next versionop

IRI: http://dataid.dbpedia.org/ns/core#nextVersion

is defined by


Next version of a DataIdPart

has domain

entity

has range

entity

previous versionop

IRI: http://dataid.dbpedia.org/ns/core#previousVersion

is defined by


previous version of a DataIdPart

has domain

entity

has range

entity

similar dataop

IRI: http://dataid.dbpedia.org/ns/core#similarData

is defined by






points to other dataset containing related data

has domain

Datasetc

has range

Datasetc

software requirementop

IRI: http://dataid.dbpedia.org/ns/core#softwareRquirement

is defined by


software needed to access the data in this distribution

has domain

Distributionc

has range

document

valid for access levelop

IRI: http://dataid.dbpedia.org/ns/core#validForAccessLevel

is defined by


Limits rights and actions an Agent is allwed to take depending on the AccessLevel chosen for this

AuthorityEntityContext.

has domain


has range

Access levelc

Data Properties

access procedure aid aid system aid uri checksum Graph name is inheritable valid from

valid until version

access proceduredp

IRI: http://dataid.dbpedia.org/ns/core#accessProcedure

is defined by


Describes the steps which have to be taken to gain access to the described data at the location of a

distribution (e.g. register an account to gain dct:accessRights).

has domain

Distributionc

has range

string

aiddp

IRI: http://dataid.dbpedia.org/ns/core#aid

is defined by






the id of an agent as string


has domain

entity

has range

string

aid systemdp

IRI: http://dataid.dbpedia.org/ns/core#aidSystem

is defined by


the aid/pid system used for this identifier (ORCID, ResearcherID etc.)


has domain

entity

has range

string

aid uridp

IRI: http://dataid.dbpedia.org/ns/core#aidURI

is defined by


uri/url provided as, or in addition to an id


has domain

entity

has range

document

checksumdp

IRI: http://dataid.dbpedia.org/ns/core#checksum

is defined by


Checksum of a file to check for correctness

has domain

has rangecrc32 checksum

md5 checksum

Graph namedp

IRI: http://dataid.dbpedia.org/ns/core#graphName


The name of the graph of this distribution in a SPARQL endpoint

has domain

Distributionc





back to ToC

has range

string

is inheritabledp

IRI: http://dataid.dbpedia.org/ns/core#isInheritable

is defined by


Defines that a context keeps intact for the next version of a DataID (if set to 'true').

has domain


has range

boolean

valid fromdp

IRI: http://dataid.dbpedia.org/ns/core#validFrom

is defined by


An AuthorityEntityContext is valid for a specific Agent from a certain point in time.

has domain


has rangedate

valid untildp

IRI: http://dataid.dbpedia.org/ns/core#validUntil

is defined by


An AuthorityEntityContext is valid for a specific Agent until a certain point in time.

has domain


has range

date

versiondp

IRI: http://dataid.dbpedia.org/ns/core#version


provides a version string for any entity

has domain

entity

has range

string


dataid


dcat

http://www.w3.org/ns/dcat#

dct


foaf

http://xmlns.com/foaf/0.1/

lvont

http://lexvo.org/ontology#

ns

http://www.w3.org/ns/

odrl

http://www.w3.org/ns/odrl/2/

owlhttp://www.w3.org/2002/07/owl#

prov


rdf


rdfs


sd

http://www.w3.org/ns/sparql-service-description#

vann

http://purl.org/vocab/vann/

vocab-deri-iehttp://vocab.deri.ie/

void

http://rdfs.org/ns/void#

wsdl

http://www.w3.org/ns/wsdl-rdf#

xsdhttp://www.w3.org/2001/XMLSchema#


Peroni.

Reasoning Violations Ontology

IRI:

http://dacura.cs.tcd.ie/data/rvo#

Date:

11/11/2015

Current version:

0.1.02

Authors:

Bojan Božić

Contributors:

Bojan Božić

Gavin Mendel-Gleason

Kevin C. Feeney

Rob Brennan


Ontology source

This ontology is distributed under a Creative Commons Attribution License - http://creativecommons.org

/licenses/by/3.0

Abstract

This ontology is used to describe reasoning violations messages.

Table of Content

Introduction1.

Classes2.

Object Properties3.

Data Properties4.


Introduction

This ontology is used to describe dacura quality service RDF reasoning violation messages. These are

generated by running an RDF/RDFS/OWL-DL reasoner over an input RDF model and allow the dacura quality

service to report any integrity violations detected at the schema or instance level. These violations report areas

where the input model is logically inconsistent or breaks RDFS/OWL semantics or axioms. Violations may be

reported as based on open world or closed world assumptions. The open world is the default OWL semantics

and can typically only detect a limited number of problems due to incomplete knowledge. The closed world

interpretation assumes that you have provided all relevant aspects of the model and is able to detect a much

wider range of violations, e.g. missing or misspelled term definitions. This is often useful during ontology

development or in a system that interprets OWL as a constraint language.

Examples:

Error Message Attributes

notSubClassOfClass

The class https://w3id.org/diopp#AcceptanceCriteria is

not a subclass of a valid class https://w3id.org

/dio#Evaluation

{ "child": "https://w3id.org

/diopp#AcceptanceC...

notSubPropertyOfProperty

http://aligned-project.eu/ontologies/dlo#isSupportedBy

is not a sub-property of a valid property

http://www.w3.org/ns/prov#wasAssociatedWith

{ "child": "http://aligned-

project.eu/ontologi...

invalidRange

ObjectProperty Range

http://www.ontologydesignpatterns.org/ont/dul

/DUL.owl#Task is not a valid range for property

http://purl.org/slo/hasTask.

{ "property": "http://purl.org

/slo/hasTask", ...

noImmediateDomainObject property http://purl.org/slo/hasOutcome has no

specified domain.


/slo/hasOutcome"...

noImmediateRangeObject property http://purl.org/slo/hasOutcome has no

specified range.


/slo/hasOutcome"...

notUniqueProperty

http://www.w3.org/2000/01/rdf-schema#comment is not

a unique property name, some property with this name

already exists

{ "property":

"http://www.w3.org

/2000/01/rdf-s...

rangeNotSubsumedInvalid range on property http://purl.org/slo/hasActivity,

due to failure of range subsumption.


/slo/hasActivity...

notIntersectionOfClass

The class :sip13 is not an intersection of a valid class

http://aligned.cs.ox.ac.uk/ontologies

/slo#SoftwareLifecycleProcess

{ "child": ":sip13", "parent":

"http://al...

Classes

Class Class Cycle Violation Class Violation Constraint Type Data Invalid at Datatype Violation

Domain Not Subsumed Violation Edge Orphan Instance Violation Element

Instance Blank Node Violation Instance Property Violation Instance Violation

Invalid Domain Violation Invalid Edge Violation Invalid Range Violation

Local Orphan Property Violation No Explicit Domain Violation No Explicit Range Violation

No Immediate Class Violation No Property Domain Violation No Property Range Violation

Non Functional Property Violation Not an Element Violation Not Base Type Element Violation

Not Domain Class Violation Not Intersection of Class Violation

Not Inverse Functional Property Violation Not Restriction Element Violation

Not Sub Class of Class Violation Not Subproperty of Property Violation

Not Super Class of Class Violation Not Union of Class Violation Not Unique Class Label Violation

Not Unique Class Name Violation Not Unique Property Name Violation

Object Invalid at Class Violation Orphan Class Violation Orphan Property Violation Property

Property Annotation Overload Violation Property Cycle Violation Property Domain Violation

Property Range Violation Property Type Overload Violation Property Violation

Range Not Subsumed Violation Schema Blank Node Violation Schema Violation Violation





Classc

IRI: http://dacura.cs.tcd.ie/data/rvo#Class

This is the class which produced a violation.

is in domain of

Defined at Linedp

is in range of

Childop, Classop, Domainop, Parentop, Parent Domainop, Parent Rangeop, Qualified onop, Rangeop

Class Cycle Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#ClassCycleViolation

The class has a class cycle.

has super-classes

Class Violationc

is in domain of

Pathdp

Class Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#ClassViolation

A violation which is caused by an inconsistent or invalid class definition.

has super-classes

Schema Violationc

has sub-classes

Class Cycle Violationc, No Immediate Class Violationc, Not Domain Class Violationc, Not Unique Class

Label Violationc, Not Unique Class Name Violationc, Orphan Class Violationc

is in domain of

Childop, Parentop

Constraint Typec

IRI: http://dacura.cs.tcd.ie/data/rvo#ConstraintType

Specifies whether the constraint exists in a closed or open world.

is equivalent to

{ closedworld , openworld }

is in range of

Constraint Typeop







Data Invalid at Datatype Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#DataInvalidAtDatatypeViolation

Not an element of enumeration or not an element of intersection or not an element of union or literal cannot

be an object.

has super-classes

Not an Element Violationc

has sub-classes

Not Base Type Element Violationc

Domain Not Subsumed Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#DomainNotSubsumedViolation

Invalid domain on a property has been caused by failure of domain subsumption.

has super-classes

Property Domain Violationc

is in domain of

Parent Domainop, Parent Properyop

Edge Orphan Instance Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#EdgeOrphanInstanceViolation

The instance has no class or an invalid domain class.

has super-classes


is in domain of

Objectop, Predicateop, Subjectop

Elementc

IRI: http://dacura.cs.tcd.ie/data/rvo#Element

This is the element which was involved in a violation.

is in domain of

Defined at Linedp

is in range of

Elementop, Valueop

Instance Blank Node Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#InstanceBlankNodeViolation

Subject, preidcate, or object is a blank node.

has super-classes

Instance Violationc

is in domain of


Instance Property Violationc





IRI: http://dacura.cs.tcd.ie/data/rvo#InstancePropertyViolation

No property class associated with property.

has super-classes

Instance Violationc

has sub-classes

Invalid Edge Violationc, Local Orphan Property Violationc, Non Functional Property Violationc, Not

Inverse Functional Property Violationc

is in domain of


Instance Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#InstanceViolation

A violation which is caused by inconsistancies on the instance level.

has super-classes

Violationc

has sub-classes

Instance Blank Node Violationc, Instance Property Violationc, No Property Domain Violationc, No

Property Range Violationc, Not an Element Violationc

Invalid Domain Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#InvalidDomainViolation

The property has an invalid domain.

has super-classes


Invalid Edge Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#InvalidEdgeViolation

Range/domain cardinality of deleted predicates not respected.

has super-classes


Invalid Range Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#InvalidRangeViolation

The property has an invalid or unimplemented range.

has super-classes

Property Range Violationc







Local Orphan Property Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#LocalOrphanPropertyViolation

No property class associated with property.

has super-classes


No Explicit Domain Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NoExplicitDomainViolation

Property has no explicit domain.

has super-classes


No Explicit Range Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NoExplicitRangeViolation

Property has no explicit range.

has super-classes


No Immediate Class Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NoImmediateClassViolation

An undefined class is used as domain for a property or the class is defined but the superclass is not or the

class is not a subclass of a defined class or the class is an intersection of a defined class but not a defined

class or the class is not an intersection of a defined class or the class is not a union of a defined class or the

class is a union but not a defined class.

has super-classes

Class Violationc

has sub-classes

Not Intersection of Class Violationc, Not Sub Class of Class Violationc, Not Super Class of Class

Violationc, Not Union of Class Violationc

No Property Domain Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NoPropertyDomainViolation

Property has no well defined domain.

has super-classes

Instance Violationc

No Property Range Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NoPropertyRangeViolation

Property has no well defined range.







has super-classes

Instance Violationc

Non Functional Property Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotFunctionalPropertyViolation

Functional property is not functional.

has super-classes



IRI: http://dacura.cs.tcd.ie/data/rvo#NotAnElementViolation

Not an element of enumeration, intersection, or union.

has super-classes

Instance Violationc

has sub-classes

Data Invalid at Datatype Violationc, Edge Orphan Instance Violationc, Not Restriction Element

Violationc, Object Invalid at Class Violationc

is in domain of

Cardinalitydp, Qualified onop, Valueop

Not Base Type Element Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotBaseTypeElementViolation

The value is not element of the specified datatype.

has super-classes

Data Invalid at Datatype Violationc

Not Domain Class Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotDomainClassViolation

The used property domain is not defined.

has super-classes

Class Violationc

Not Intersection of Class Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotIntersectionOfClassViolation

The class is an intersection of a defined class, but not a defined class or the class is not an intersection of a

defined class.

has super-classes


Orphan Class Violationc

Not Inverse Functional Property Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotInverseFunctionalPropertyViolation







Functional property is not functional.

has super-classes


Not Restriction Element Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotRestrictionElementViolation

No values from restriction class or some values not from restriction class or cardinality too small on restriction

class or cardinality too large on restriction class or cardinality unequal on restriction class or qualified

cardinality too small on restriction class or qualified cardinality too large on restriction class or qualified

cardinality unequal on restriction class or hasValue constraint violated.

has super-classes


Not Sub Class of Class Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotSubClassOfClassViolation

The class is not a subclass of a defined class.

has super-classes



Not Subproperty of Property Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotSubpropertyOfPropertyViolation

The property is not a subproperty of a valid property.

has super-classes

Orphan Property Violationc

Not Super Class of Class Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotSuperClassOfClassViolation

The class is not a superclass of a defined class.

has super-classes


Not Union of Class Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotUnionOfClassViolation

The class is not a union of a defined class or is a union of a defined class but not defined itself.

has super-classes



Not Unique Class Label Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotUniqueClassLabelViolation







Class does not have exactly one label.

has super-classes

Class Violationc

Not Unique Class Name Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotUniqueClassNameViolation

The class or restriction is not unique (i.e. there is another existing class with the same identifier).

has super-classes

Class Violationc

Not Unique Property Name Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#NotUniquePropertyNameViolation

Another property exists with the same identifier.

has super-classes

Property Violationc

Object Invalid at Class Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#ObjectInvalidAtClassViolation

Not an lement of enumeration or more than one branch of disjoint union is valid or element is not valid at any

class of union or complement is valid.

has super-classes



IRI: http://dacura.cs.tcd.ie/data/rvo#OrphanClassViolation

The class is not a subclass, intersection, or union of a valid class.

has super-classes

Class Violationc

has sub-classes

Not Intersection of Class Violationc, Not Sub Class of Class Violationc, Not Union of Class Violationc

Orphan Property Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#OrphanPropertyViolation

The property is not a sub-property of a valid property.

has super-classes

Property Violationc

has sub-classes

Not Subproperty of Property Violationc

Propertyc

IRI: http://dacura.cs.tcd.ie/data/rvo#Property






This is the property which produced a violation.

is in domain of

Defined at Linedp

is in range of

Childop, Parentop, Parent Properyop, Propertyop

Property Annotation Overload Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#PropertyAnnotationOverloadViolation

The property is defined as a property and as an annotation property.

has super-classes

Property Violationc

Property Cycle Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#PropertyCycleViolation

The property class has a cycle.

has super-classes

Property Violationc

is in domain of

Pathdp


IRI: http://dacura.cs.tcd.ie/data/rvo#PropertyDomainViolation

Property has no well defined domain.

has super-classes

Property Violationc

has sub-classes

Domain Not Subsumed Violationc, Invalid Domain Violationc, No Explicit Domain Violationc

is in domain of

Domainop, Rangeop


IRI: http://dacura.cs.tcd.ie/data/rvo#PropertyRangeViolation

Property has no well defined range.

has super-classes

Property Violationc

has sub-classes

Invalid Range Violationc, No Explicit Range Violationc, Range Not Subsumed Violationc

Property Type Overload Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#PropertyTypeOverloadViolation

The property is an object property and a datatype property.

has super-classes






Property Violationc

Property Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#PropertyViolation

A violation which is caused by an inconsistent or invalid property definition.

has super-classes

Schema Violationc

has sub-classes

Not Unique Property Name Violationc, Orphan Property Violationc, Property Annotation Overload

Violationc, Property Cycle Violationc, Property Domain Violationc, Property Range Violationc, Property

Type Overload Violationc, Schema Blank Node Violationc

is in domain of

Childop, Parentop

Range Not Subsumed Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#RangeNotSubsumedViolation

Invalid range on a property has been caused by failure of range subsumption.

has super-classes


is in domain of

Parent Properyop, Parent Rangeop

Schema Blank Node Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#SchemaBlankNodeViolation

Subject, predicate, or object is a blank node.

has super-classes

Property Violationc

is in domain of


Schema Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#SchemaViolation

A violation which is caused by inconsistancies on the schema level.

has super-classes

Violationc

has sub-classes

Class Violationc, Property Violationc

Violationc

IRI: http://dacura.cs.tcd.ie/data/rvo#Violation

Generic class for all kinds of violations within Dacura.

has sub-classes

Instance Violationc, Schema Violationc






is in domain of

Best Practicedp, Classop, Constraint Typeop, Elementop, Infodp, Messagedp, Propertyop

Object Properties

Child Class Constraint Type Domain Element Object Parent Parent Domain

Parent Propery Parent Range Predicate Property Qualified on Range Subject Value

Childop

IRI: http://dacura.cs.tcd.ie/data/rvo#child

Involved child class or property.

has domain

Class Violationc

Property Violationc

has range

Classc

Propertyc

Classop

IRI: http://dacura.cs.tcd.ie/data/rvo#class

A property which assignes the class that produced a violation to the respective violation class.

has domain

Violationc

has range

Classc

Constraint Typeop

IRI: http://dacura.cs.tcd.ie/data/rvo#constraintType

Type of constraint on a violation - could be openworld or closedworld.

has domain

Violationc

has range

Constraint Typec

Domainop

IRI: http://dacura.cs.tcd.ie/data/rvo#domain

The intended domain class of a property domain violation.

has domain


has range

Classc

Elementop





IRI: http://dacura.cs.tcd.ie/data/rvo#element

A property which assignes the element that was involved in a violation to the respective element violation

class.

has domain

Violationc

has range

Elementc

Objectop

IRI: http://dacura.cs.tcd.ie/data/rvo#object

The object of a triple involved in a violation.

has domain





has range

resourcec

Parentop

IRI: http://dacura.cs.tcd.ie/data/rvo#parent

Involved parent class or property.

has domain

Class Violationc

Property Violationc

has range

Classc

Propertyc

Parent Domainop

IRI: http://dacura.cs.tcd.ie/data/rvo#parentDomain

Parent domain of a domain not subsumed violation.

has domain


has range

Classc

Parent Properyop

IRI: http://dacura.cs.tcd.ie/data/rvo#parentProperty

Marks the parent property for range and domain not subsumed violations.






has domain



has range

Propertyc

Parent Rangeop

IRI: http://dacura.cs.tcd.ie/data/rvo#parentRange

Parent range of a range not subsumed violation.

has domain


has range

Classc

Predicateop

IRI: http://dacura.cs.tcd.ie/data/rvo#predicate

The predicate of a triple involved in a violation.

has domain





has range

resourcec

Propertyop

IRI: http://dacura.cs.tcd.ie/data/rvo#property

A property which assignes the property that produced a violation to the respective violation class.

has domain

Violationc

has range

Propertyc

Qualified onop

IRI: http://dacura.cs.tcd.ie/data/rvo#qualifiedOn

The relation between a not an elment violation an the class the element was assigned to.

has domain


has range

Classc

Rangeop

IRI: http://dacura.cs.tcd.ie/data/rvo#range

The intended range class of a property domain violation.





has domain


has range

Classc

Subjectop

IRI: http://dacura.cs.tcd.ie/data/rvo#subject

The subject of a triple involved in a violation.

has domain





has range

resourcec

Valueop

IRI: http://dacura.cs.tcd.ie/data/rvo#value

The value of an element involved in the not an element violation.

has domain


has range

Elementc

Data Properties

Best Practice Cardinality Defined at Line Info Message Path

Best Practicedp

IRI: http://dacura.cs.tcd.ie/data/rvo#bestPractice

This is a generic property which indicates whether a violation is considered only best practice or more

serious.

has domain

Violationc

has range

boolean

Cardinalitydp

IRI: http://dacura.cs.tcd.ie/data/rvo#cardinality

Defines the cardinality of a not an element violation.

has domain


has range

non negative integer





back to ToC

Defined at Linedp

IRI: http://dacura.cs.tcd.ie/data/rvo#definedAtLine

This is a generic property which indicates where the class, property, or element that caused the violation has

occured in the ontology.

has domain

Classc

Elementc

Propertyc

has range


Infodp

IRI: http://dacura.cs.tcd.ie/data/rvo#info

This is a generic property which allows publishing additional context to a message.

has domain

Violationc

has range

string

Messagedp

IRI: http://dacura.cs.tcd.ie/data/rvo#message

This is a general property which can be used to attach the original error message provided by a reasoner.

has domain

Violationc

has range

string

Pathdp

IRI: http://dacura.cs.tcd.ie/data/rvo#path

Defines the path of the cycle violation.

has domain

Class Cycle Violationc

Property Cycle Violationc

has range

string


default namespace


dc


images


owl


rdf


rdfs


rvo


xsd



Peroni.

Enterprise Information Processing Domain-specific Meta-Model

IRI:

http://aligned-project.eu/ontologies/eipdm

Date:

05-02-2016

Current version:

1.11.000

Authors:

Bojan Bozic ([email protected])

Publisher:

Wolters Kluwer


http://aligned-project.eu/ontologies/dlo (visualise it with LODE)


Ontology source

Abstract

This ontology provides a description of the data lifecycle for enterprise information processing. It models both

the data and the software lifecycle on the example of the JURION platform. Furthermore, it supports different

kinds of entities, users, and versioning.

Table of Content

Introduction1.

Classes2.

Object Properties3.

Data Properties4.


Introduction

The purpose of the Enterprise Information Processing Domain-specific Meta-Model is to provide a set of

concrete entities, agents, activities, and roles to represent the data engineering process. It is based on the

general Data Lifecycle Ontology.

The initial information gathered to build the domain-specific enterprise information processing metamodel is

based on the JURION use case. The JURION use case includes both processes for data and software

development and therefore uses the data lifecycle ontology and the software lifecycle ontology.

The ontology models mandatory data requirements for specific processes and checks if they are fulfilled. The

location of error occurence within the process is registered and the type of error or incosistency asserted.

Furthermore, we capture how many errors occured, in which dataset they were detected, what was responsible

for it, who fixed it, when was it fix, and how long does fixing take. Captured information about the dataset

include publishing, versioning, and properties. Functionalities are associated to specific datasets and changing

of data is tracked. Other areas of interest are links and how they behave especially when linking eternal data

sources as well as mapping ontologies and information of processes about external data changes.

This ontology imports the W3C PROV ontology available at http://www.w3c.org/TR/prov-o/. It is derived from

the Data Lifecycle Ontology available at http://aligned-project.eu/ontologies/dlo.




Classes

CMS Expert Content Architect Controlled Vocabulary Customer Data Authoring Data Source

Internal Data Issue Ticket Legal Domain Expert Legal Editor Product Owner

Requirements Document Schema Authoring Schema Change Schema Expert

Server Infrastructure Software Analyst Software Developer Software Manager Software Tester

Source Code Source File Test Case Test File Testing Suite Transformation Version

CMS Expertc

IRI: http://aligned-project.eu/ontologies/eipdm#CMSExpert

Person who is an expert in development and management of content management systems.

has super-classes

data process personc

Content Architectc

IRI: http://aligned-project.eu/ontologies/eipdm#ContentArchitect

Person responsible for the content of a software system.

has super-classes

data engineerc

Controlled Vocabularyc

IRI: http://aligned-project.eu/ontologies/eipdm#ControlledVocabulary

A controlled vocabulary process outcome.

has super-classes








process outcomec

Customerc

IRI: http://aligned-project.eu/ontologies/eipdm#Customer

Person who is involved in requirement engineering and usage of the software or data product.

has super-classes

userc

Data Authoringc

IRI: http://aligned-project.eu/ontologies/eipdm#DataAuthoring

Generation of data as a data lifecycle process.

has super-classes

authoringc

Data Sourcec

IRI: http://aligned-project.eu/ontologies/eipdm#DataSource

The data source for a specific kind of data.

has super-classes

process outcomec

Internal Datac

IRI: http://aligned-project.eu/ontologies/eipdm#InternalData

Unspecified internal system data.

has super-classes

process outcomec

Issue Ticketc

IRI: http://aligned-project.eu/ontologies/eipdm#IssueTicket

A bug report in a software system.

has super-classes

process outcomec

Legal Domain Expertc

IRI: http://aligned-project.eu/ontologies/eipdm#LegalDomainExpert

Person who is an expert for legal issues in a certain domain.

has super-classes

domain expertc

Legal Editorc







IRI: http://aligned-project.eu/ontologies/eipdm#LegalEditor

Person who edits legal documents for a software or data system.

has super-classes


Product Ownerc

IRI: http://aligned-project.eu/ontologies/eipdm#ProductOwner

Person who owns and uses the end product.

has super-classes


Requirements Documentc

IRI: http://aligned-project.eu/ontologies/eipdm#RequirementsDocument

A requirements document as output of requirements engineering.

has super-classes

process outcomec

Schema Authoringc

IRI: http://aligned-project.eu/ontologies/eipdm#SchemaAuthoring

Creation of a schema as a data lifecycle process.

has super-classes

authoringc

Schema Changec

IRI: http://aligned-project.eu/ontologies/eipdm#SchemaChange

A document describing the change of schema for a sofware or data system.

has super-classes

process outcomec

Schema Expertc

IRI: http://aligned-project.eu/ontologies/eipdm#SchemaExpert

Person who is an expert in development of schemas for a data system.

has super-classes

data engineerc

Server Infrastructurec

IRI: http://aligned-project.eu/ontologies/eipdm#ServerInfrastructure

The server infrastructure on which a software or data system is deployed.

has super-classes








process outcomec

Software Analystc

IRI: http://aligned-project.eu/ontologies/eipdm#SoftwareAnalyst

Person responsible for analysing software systems and requirements engineering.

has super-classes


Software Developerc

IRI: http://aligned-project.eu/ontologies/eipdm#SoftwareDeveloper

Person responsible for development of software systems.

has super-classes


Software Managerc

IRI: http://aligned-project.eu/ontologies/eipdm#SoftwareManager

Person responsible for management of software engineering projects.

has super-classes


Software Testerc

IRI: http://aligned-project.eu/ontologies/eipdm#SoftwareTester

Person responsible for testing software systems before releases.

has super-classes


Source Codec

IRI: http://aligned-project.eu/ontologies/eipdm#SourceCode

An unspecified amount (collection) of source code in a specific programming language.

has super-classes

process outcomec

Source Filec

IRI: http://aligned-project.eu/ontologies/eipdm#SourceFile

A source file containing source code in a specific programming language.

has super-classes

process outcomec

Test Casec






IRI: http://aligned-project.eu/ontologies/eipdm#TestCase

A test case which tests one specific aspect of a software system.

has super-classes

process outcomec

Test Filec

IRI: http://aligned-project.eu/ontologies/eipdm#TestFile

A file containing test suites and/or test cases for a software system.

has super-classes

process outcomec

Testing Suitec

IRI: http://aligned-project.eu/ontologies/eipdm#TestingSuite

A collection of test cases for a software system.

has super-classes

process outcomec

Transformationc

IRI: http://aligned-project.eu/ontologies/eipdm#Transformation

Transformation is a data and software lifecycle process which is the base class for several subprocesses for

changing data or software artefacts.

has super-classes

data lifecycle processc

software lifecycle processc

Versionc

IRI: http://aligned-project.eu/ontologies/eipdm#Version

Versioning model according to Semantic Versioning (http://semver.org/).

has super-classes

has patchdp some non negative integer

has majordp some non negative integer

has minordp some non negative integer

is in domain of

has build metadatadp, has majordp, has minordp, has patchdp

is in range of

has versionop

Object Properties

has version

has versionop





back to ToC

IRI: http://aligned-project.eu/ontologies/eipdm#hasVersion

has domain

process outcomec

has range

Versionc

Data Properties

has build metadata has major has minor has patch

has build metadatadp

IRI: http://aligned-project.eu/ontologies/eipdm#hasBuildMetadata

Build meta-data as string is a place for potential future growth of the model, depending on use cases.

has domain

Versionc

has range

string

has majordp

IRI: http://aligned-project.eu/ontologies/eipdm#hasMajor

has domain

Versionc

has range

decimal


has minordp

IRI: http://aligned-project.eu/ontologies/eipdm#hasMinor

has domain

Versionc

has range


has patchdp

IRI: http://aligned-project.eu/ontologies/eipdm#hasPatch

has domain

Versionc

has range



default namespace

http://aligned-project.eu/ontologies/eipdm#

dc


dlo


images


ontologies


owl


rdf


rdfs


slo


xsd



Peroni.

E-research in the Social Sciences and Humanities

IRI:

http://aligned-project.eu/ontologies/eres#

Date:

11/02/2016

Current version:

2.00.000

Authors:

Bojan Božić

Rob Brennan

Contributors:

Kevin Feeney

Publisher:



https://w3id.org/dlo (visualise it with LODE)


Ontology source


/licenses/by/3.0

Abstract

This ontology provides a description of the data lifecycle for e-research in social sciences and humanities.

Table of Content

Introduction1.

Classes2.

Object Properties3.

Named Individuals4.


Introduction

The purpose of the ALIGNED E-research in the Social Sciences and Humanities domain-specific metamodel is

to provide a set of concrete entities, agents, activities, and roles to represent the data engineering process for

this domain. It is based on the Seshat use case within ALIGNED. It specialises the ALIGNED generic Data

Lifecycle Ontology (DLO) and imports the W3C PROV ontology. This model adds support for specific external

data sources for datasets like wikis and webpages. It adds new entities to represent candidate data for

inclusion in a dataset, reports of historical events and historical interpretations created by domain experts. It

extends the set of data lifecycle processes to include data curation activities such as manual data extraction

and data publishing. Finally new roles are defined for all the actors in the Seshat databank project: readers,

experts, research assistants and so forth that work in the Seshat semi-automated data curation pipelines or

workflows. This ontology imports the W3C PROV ontology available at http://www.w3c.org/TR/prov-o/. It is

derived from the Data Lifecycle Ontology available at http://aligned-project.eu/ontologies/dlo.




Classes

Administrators Analysts Candidate Contributor Data Architect Editor Expert Harvester

Interpretation Manual Extraction Publishing Reader Report Research Assistant Scraping

Wiki Wiki page

Administratorsc

IRI: http://aligned-project.eu/ontologies/eres#Adminstrators

Technical administrators can manage the data curation and publication platform or servers to deal with

changes in data, schemata, collection tools and publication formats or tools (e.g., visualizations) over time.

has super-classes

system adminc

Analystsc

IRI: http://aligned-project.eu/ontologies/eres#Analysts

Statisticians and mathematical modelers who prepare and analyze data from the dataset to investigate

scientific questions.

has super-classes

user

Candidatec






IRI: http://aligned-project.eu/ontologies/eres#Candidate

A data item or fact which has been selected for examination to see if it is going to be included into the

dataset.

has super-classes

data entity

Contributorc

IRI: http://aligned-project.eu/ontologies/eres#Contributor

Non-technical users, such as historians and archaeologists, that can easily add data to the daatsets and

update existing data.

has super-classes

domain expert

has sub-classes

Expertc, Harvesterc, Research Assistantc

Data Architectc

IRI: http://aligned-project.eu/ontologies/eres#DataArchitect

Knowledge engineers who can make changes to the dataset schema (data structures) over time and manage

transitions between versions of the schema without breaking databank integrity (maintaining and assuring the

accuracy and consistency of data over its entire life-cycle).

has super-classes

data engineer

Editorc

IRI: http://aligned-project.eu/ontologies/eres#Editor

Data collection administrators who can moderate, correct, and manage the data in the system over time.

has super-classes

data engineer

domain expert

system adminc

Expertc

IRI: http://aligned-project.eu/ontologies/eres#Expert

A subject matter expert that is working on the Seshat project.

has super-classes

Contributorc

is in range of

Expertop

Harvesterc

IRI: http://aligned-project.eu/ontologies/eres#Harvester

A data collection role that involves manual collection of facts for inclusion in the dataset or human validation

of candidates to create reports in the dataset. Normally filled by research assistants or crow-sourced

volunteers.







has super-classes

Contributorc

Interpretationc

IRI: http://aligned-project.eu/ontologies/eres#Interpretation

A data item or fact which has been validated or selected by a domain expert as reflecting their view of the

world as expressed in the dataset.

has super-classes

data entity

Manual Extractionc

IRI: http://aligned-project.eu/ontologies/eres#ManualExtraction

The activity of manually generating cadidates for inclusion into a dataset. For example this may be used for

the activity of research assistants.

has super-classes

extraction

Publishingc

IRI: http://aligned-project.eu/ontologies/eres#Publishing

The activity of publishing data on the web as ready for use by Readers.

has super-classes

data lifecycle process

Readerc

IRI: http://aligned-project.eu/ontologies/eres#Reader

General end-users of the data-sets that have no ability to directly change them.

has super-classes

user

Reportc

IRI: http://aligned-project.eu/ontologies/eres#Report

A data item or fact which has been approved for inclusion in the dataset.

has super-classes

data entity

Research Assistantc

IRI: http://aligned-project.eu/ontologies/eres#ResearchAssistant

A research assistant working on the Seshat project.

has super-classes

Contributorc

is in range of






Research Assistantop

Scrapingc

IRI: http://aligned-project.eu/ontologies/eres#Scraping

The activity of automatically converting a semi or unstructured web data source into a structured data source.

has super-classes

extraction

Wikic

IRI: http://aligned-project.eu/ontologies/eres#wiki

A wiki used as a source of data for generating candidates for inclusion in the dataset.

has super-classes

data source

Wiki pagec

IRI: http://aligned-project.eu/ontologies/eres#wikiPage

A particular wiki page idenified by a praticular URL that is used as a source of data for generating candidates

for inclusion in the dataset.

has super-classes

data source

Object Properties

Expert Research Assistant

Expertop

IRI: http://aligned-project.eu/ontologies/eres#expert

Designates the Expert associated with the valdiation of a specific Seshat data entity.


was attributed to

has domain

data entity

has range

Expertc

Research Assistantop

IRI: http://aligned-project.eu/ontologies/eres#ra

Designates the RA associated with the creation of a specific Seshat data entity.


was attributed to

has domain

data entity




back to ToC

has range

Research Assistantc

Named Individuals

Dacura Platform Dacura Quality Service Dacura Scraper Service

Dacura Platformni

IRI: http://aligned-project.eu/ontologies/eres#dacuraPlatform

The base Dacura platform, responsible for user management and other basic services.

belongs to

data software agent

Dacura Quality Serviceni

IRI: http://aligned-project.eu/ontologies/eres#dacuraQualityService

The Dacura Quality Service provides a REST interface for schema and instance checking. It acts as a

validation service and a data integrity gateway to the Dacura triplestore.

belongs to

data software agent

Dacura Scraper Serviceni

IRI: http://aligned-project.eu/ontologies/eres#dacuraScraperService

The Dacura Scraper Service provides an interface for scraping data from the Sesaht wiki and generating TSV

dump files.

belongs to

data software agent


default namespace

http://aligned-project.eu/ontologies/eres#

data

http://www.aligned-project.eu/data/

dc


dlo


owl


prov


rdf


rdfs


w3id-org

https://w3id.org/

xsd



Peroni.

Crowd-sourced Public Dataset Lifecycle Ontology.

IRI:

http://aligned-project.eu/ontologies/cspdo#

Date:

04/02/2016

Current version:

1.01.000

Authors:

Rob Brennan

Contributors:

Alan Meehan

Bojan Bozic

Dimitris Kontokostas

Markus Freudenbergn

Publisher:

Wolters Kluwer


http://aligned-project.eu/ontologies/dlo (visualise it with LODE)

http://aligned.cs.ox.ac.uk/ontologies/slo# (visualise it with LODE)

http://dataid.dbpedia.org/ns/core# (visualise it with LODE)

http://rdfunit.aksw.org/ns/core# (visualise it with LODE)

http://www.w3.org/ns/prov# (visualise it with LODE)


Ontology source


/licenses/by/3.0

Table of Content

Introduction1.

Classes2.

Named Individuals3.

Annotation Properties4.


Introduction

This ontology is used to describe the domain-specific extensions to the ALIGNED data lifecycle model ontology

(DLO) and software lifecycle ontology (SLO) for crowd-sourced public datasets based on the DBpedia use

case within the ALIGNED project. Over time generic features may be migrated to the upper ontology.

The current scope of this ontology is to support extensions needed for DBpedia scenarios within Phase 2 of

the ALIGNED project. Thus there is a focus on the validation activities. DBpedia is a large-scale extraction

project of unstructured & semi-structured data from different Wikipedia language editions to RDF. This

extraction is achieved from a modular extraction framework that is customized to handle multilingualism and

structural differences between different Wikipedia language editions. The latest DBpedia release (v. 2016)

generated a total of three billion facts from 125 localized versions. As Wikipedia evolves over time the code

should be able to adapt to these changes. However, identifying errors at this data scale becomes very hard

and validation workflows must be established that will ensure the quality of the extracted data.

ALIGNED is tackling these challenges with data validation and interlink validation tools that communicate their

results though the ALIGNED vocabularies.




Classes

DBpedia Release Extraction DBpedia Release Post-Processing DBpedia Release Pre-Processing

DBpedia Release Process DBpedia Release Publishing Developer Extraction Manager

Extraction Software or Agent Mapping Editor Ontology Editor Release Manager

DBpedia Release Extractionc

IRI: http://aligned-project.eu/ontologies/cspdo#ExtractionExecution

Running the extraction framework for the actual extraction of data from Wikipedia.

has super-classes

extractionc

DBpedia Release Post-Processingc

IRI: http://aligned-project.eu/ontologies/cspdo#PostProcessing

Running checks and enhancements to the data generated by the DBpedia extraction framework before

publishing.

has super-classes

evolutionc

interlinkingc

qualityc

DBpedia Release Pre-Processingc

IRI: http://aligned-project.eu/ontologies/cspdo#PreProcessing







Releasing a DBpedia dataset is a complex procedure that involves a lot of pre-processing steps performed

before the actual extraction of data from Wikipedia.

has super-classes

extractionc

DBpedia Release Processc

IRI: http://aligned-project.eu/ontologies/cspdo#Release

Releasing a DBpedia dataset is a complex procedure that involves a lot of pre-processing steps, the actual

extraction, additional postprocessing steps and finally the dataset publishing step. This activity is performed

by the release manager using the extraction framework and DBpedia tools.

has super-classes

processc

DBpedia Release Publishingc

IRI: http://aligned-project.eu/ontologies/cspdo#Publishing

Publishing a new DBpedia release on the web.

has super-classes

processc

Developerc

IRI: http://aligned-project.eu/ontologies/cspdo#Developer

DBpedia team members or community who write code for the extraction framework or tools

has super-classes


Extraction Managerc

IRI: http://aligned-project.eu/ontologies/cspdo#ExtractionManager

DBpedia team members who run the extraction process for a given DBpedia release.

has super-classes


Extraction Software or Agentc

IRI: http://aligned-project.eu/ontologies/cspdo#ExtractionAgent

Software agents that perform the extraction such as DBpedia live.

has super-classes

software agent

has members

DBpedia Extraction Frameworkni

Mapping Editorc

IRI: http://aligned-project.eu/ontologies/cspdo#MappingEditor






Community members who edit the DBpedia mapping wiki.

has super-classes

data engineerc

Ontology Editorc

IRI: http://aligned-project.eu/ontologies/cspdo#OntologyEditor

DBpedia foundation members that edit the DBpedia ontology.

has super-classes

data engineerc

Release Managerc

IRI: http://aligned-project.eu/ontologies/cspdo#ReleaseManager

DBpedia team members that are responsible for the actions leading to a given release of DBpedia.

has super-classes


Named Individuals

DBpedia Extraction Framework DBpedia Ontology Infobox to Ontology mappings Wikipedia

DBpedia Extraction Frameworkni

IRI: http://aligned-project.eu/ontologies/cspdo#dBpediaExtractionFramework

The source code used to extract knowledge from Wikipedia.

belongs to

Extraction Software or Agentc

DBpedia Ontologyni

IRI: http://aligned-project.eu/ontologies/cspdo#dBpediaOntology

Crowdsourced OWL ontology describing DBpedia concepts and properties.

belongs to

data entityc

datasetc

Infobox to Ontology mappingsni

IRI: http://aligned-project.eu/ontologies/cspdo#infoboxToOntologyMappings

Crowdsourced mappings between the DBpedia ontology and Wikipedia infoboxes.

belongs to

data entityc

datasetc


back to ToC or Annotation Property ToC

back to ToC

Wikipediani

IRI: http://aligned-project.eu/ontologies/cspdo#wikipedia

The original input source for DBpedia.

belongs to

data sourcec

datasetc

Annotation Properties

has sub process

has sub processap

IRI: http://aligned-project.eu/ontologies/dlo#hasSubProcess


default namespace

http://aligned-project.eu/ontologies/cspdo#

core


data

http://www.aligned-project.eu/data/

dc


dlo


ontologies


owl


prov


rdf


rdfs


xsd



Peroni.



Applying the DIO design pattern to PoolParty

IRI:

https://w3id.org/diopp

Date:

21-01-2016

Current version:

1.0.000

Authors:

Monika Solanki ([email protected])

Contributors:

Semantic Web Company - Christian Mader, Helmut Nagy, Andreas Koller


https://w3id.org/dio# (visualise it with LODE)

Other visualisation:Ontology source

Table of Content

Introduction1.

Classes2.

Object Properties3.

Data Properties4.

Named Individuals5.


Introduction

The aim of the ontology is to integrate the datasets generated through requirements specification and the

issues raised during their implementation. This ontology covers the mappings defined between the PoolParty

conceptualisation and the DIO ontology. The mappings are further supported by the figures illustrated here. An

example illustrating the mapping can be found here

Classes

acceptance criteria affected component g r i p s requirement Issue Type j i r a design issue

precondition

acceptance criteriac

IRI: https://w3id.org/diopp#AcceptanceCriteria

has super-classes

evaluation

affected componentc

IRI: https://w3id.org/diopp#AffectedComponent

has super-classes

componentc








g r i p s requirementc

IRI: https://w3id.org/diopp#GRIPSRequirement

has super-classes

design requirement

Issue Typec

IRI: https://w3id.org/diopp#IssueType

An entity representing the type of an issue.

has members

storyni

j i r a design issuec

IRI: https://w3id.org/diopp#JIRADesignIssue

has super-classes

design issue

(has affected componentop some affected componentc) and (has watcherop only agent) and (belongs

toop exactly 1 ji r a spacec) and (has assigneeop exactly 1 agent) and (has priority typeop exactly 1

priority typec) and (has reporterop exactly 1 agent) and (has resolution typeop exactly 1 resolution

typec) and (is of issue typeop exactly 1 Issue Typec)

preconditionc

IRI: https://w3id.org/diopp#Precondition

has super-classes

assumption

Object Properties

belongs to has affected component has assignee has priority type has reporter

has resolution type has version type has watcher is of issue type

belongs toop

IRI: https://w3id.org/diopp#belongsTo

The relationship between an issue and the space it belongs to.

has affected componentop

IRI: https://w3id.org/diopp#hasAffectedComponent

The relationship between an issue and the components it affects.

has assigneeop

IRI: https://w3id.org/diopp#hasAssignee








The relationship between an issue and the agent to whom it is assigned.

has priority typeop

IRI: https://w3id.org/diopp#hasPriorityType

The relationship between an issue and its priority type.

has reporterop

IRI: https://w3id.org/diopp#hasReporter

The relationship between an issue and the agent who reported the issue.



was attributed to

has resolution typeop

IRI: https://w3id.org/diopp#hasResolutionType

The relationship between an issue and its resolution type.

has version typeop

IRI: https://w3id.org/diopp#hasVersionType

The relationship between an issue and its version type.

has watcherop

IRI: https://w3id.org/diopp#hasWatcher

The relationship between an issue and the agent watching the issue.

is of issue typeop

IRI: https://w3id.org/diopp#isOfIssueType

The relationship between an issue and its type.

Data Properties

estimated time effort has due date update date

estimated time effortdp

IRI: https://w3id.org/diopp#estimatedTimeEffort

The time effort estimated to resolve a design issue.







has due datedp

IRI: https://w3id.org/diopp#hasDueDate

The due date for an issue.


has range

date time

update datedp

IRI: https://w3id.org/diopp#updateDate

The update date for an issue.

Named Individuals

blocker critical development space idea space major minor story support space trivial

unresolved

blockerni

IRI: https://w3id.org/diopp#blocker

A priority type for an issue specific to PoolParty

belongs to

priority typec

criticalni

IRI: https://w3id.org/diopp#critical


belongs to

priority typec

development spaceni

IRI: https://w3id.org/diopp#DevelopmentSpace

A JIRA space

belongs to

ji r a spacec

idea spaceni

IRI: https://w3id.org/diopp#IdeaSpace

A JIRA space

belongs to







back to ToC

ji r a spacec

majorni

IRI: https://w3id.org/diopp#major


belongs to

priority typec

minorni

IRI: https://w3id.org/diopp#minor


belongs to

priority typec

storyni

IRI: https://w3id.org/diopp#story

An issue type for JIRA

belongs to

Issue Typec

support spaceni

IRI: https://w3id.org/diopp#supportSpace

A JIRA space

belongs to

ji r a spacec

trivialni

IRI: https://w3id.org/diopp#trivial


belongs to

priority typec

unresolvedni

IRI: https://w3id.org/diopp#unresolved

The resolution type of an issue specific to PoolParty

belongs to

resolution typec


default namespace

https://w3id.org/diopp#

dc


dio


owl


prov


rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#

rdfs


skos

http://www.w3.org/2004/02/skos/core#

terms


w3id-org

https://w3id.org/

xsd



Peroni.

Documents

ALIGNEDaligned-project.eu/wordpress/wp-content/uploads/...0.5 22/2/2016 TCD Final Quality Check Declan O’Sullivan 1.0 24/2/2016 Release Candidate Rob Brennan 1.01 29/2/2016 Final