A critical and often overlooked aspect underlying the design and consequent realisation of an artifact is its design intent. Given the highly distributed and diverse nature of work ows in today's design environments, the need to have a shared understanding of the design intent, to enable e ective communication and coordination between the development teams is crucial. In this paper we present DIO: a generic content ontology design pattern that provides the much required conceptualisation needed to capture the knowledge generated during design phases. We further show, how DIO can be specialised to generate a pattern SDI (Software Design Intent) that enables the capturing of knowledge during Software design phases.
The process of systematically designing an artifact is a time-consuming and laborious task. Typically, several iterations, deliberations and informal discussions are undertaken before a nal agreement can be reached, on the features and attributes that need to be included in the concrete realisation of the artifact.
This has huge repercussions as design reuse becomes con ned to the scope
of the agents involved in the core design process. The arguments raised against
speci c potential solutions and the justi cations supporting several rejected
solutions cannot be exploited to inform future designs. The knowledge engineering
that encompasses the capturing of the \Design Intent" or the \Design rationale"
is therefore now a core requirement for most design environments. While several
e orts in the past have focused on representing design intents, many of them
are informal speci cation, developed for speci c domains such as product
design [
In this paper we present a generic content ontology design pattern, DIO (Design Intent Ontology)1 for formally harnessing the intents or the rationales that emerge or are generated during the processes that underlie modern design decision phases. DIO is a domain agnostic pattern and most domain speci c design rationale models will specialise from DIO. It provides a high level conceptualisation of the typical entities that designers encounter during the phases of designing artifacts. A signi cant advantage of DIO over existing design intent frameworks is its direct mapping to PROV2. 2 2.1
DIO provides a minimalistic abstraction and de nes conceptual, generic entities for the modelling of semantically enriched knowledge required to capture the intents or rationale behind the design of an artifact. The pattern can be specialised to de ne domain speci c design intents. 2.2
Given the requirements above, we de ne competency questions that motivate the design of a pattern-oriented conceptualisation for design intents. { What are the solution choices for a design problem? { Which functional requirements are being ful lled by the accepted design solution? { What are the alternative solutions to an accepted solution? { What are the arguments against a proposed solution? { What are the justi cations for a proposed solution? { Which agent has corroborated a solution? { What assumptions have been made in arriving at a speci c solution? { What is the status of a design issue? 2.3
Some of the key concepts and relationships encapsulating the data model de ned by the pattern are described below. Note that several entities in DIO extend from or exploit concepts and relationships de ned in PROV-O as further illustrated in Figure 1.
{ Design: An entity representing the speci cation of an object, manifested by one or more agents, intended to accomplish goals, in a particular environment, using a set of components, satisfying a set of requirements, subject to constraints. 1http://www.essepuntato.it/lode/owlapi/http://purl.org/dio/ 2http://w3.org/ns/prov# { DesignIntent: An entity representing 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. { DesignIssue, DesignProblem, DesignGoal, DesignQuestion: An entity representing the problem, goal, question or issue the design intent aims to address. { MandatedSolution: An entity representing the solution accepted as a result of the design deliberation process. { Argument: An entity representing the argument presented against a potential solution. { Justification: An entity representing the justi cation presented in support of a potential solution. { fulfillsRequirements: a relationship that identi es the design requirement being ful lled by the design. { hasStatus: a relationship that identi es the status of the design issue. Typically values are, active, terminated, onHold and resolved. { usesAssumption: a relationship that identi es the assumptions that form the basis of a solution. 2.4
The Software Design Intent (SDI) ontology is a minimalistic specialisation of DIO to capture the design intent during the Software design phases. As illustrated in Figure 2, SDI specialises DIO by extending the class Design. It associates the activity of software development, SoftwareDevelopment, with the design by using prov:used. Finally the software that is produced is related to the software development activity using prov:wasGeneratedBy. 5
The need for the representation of design intents, that originate to solve a typical design problem or a design issue, in order to ful ll a design requirement is universal across all domains. It is extremely critical to curate this knowledge for posterity and inform future generations of designs. In this paper, we have proposed a generic content ontology design pattern, DIO, that can be applied in a domain agnostic way in various design decision phases. We have shown how a minimalistic extension of DIO for the domain of Software Engineering can be utilised to associate software design rationales with the accepted software design. The work is currently in its initial stages and much still needs to be done. In future we aim to apply the pattern, for querying and deriving inferences over the knowledge curated from several design projects which are currently in various phases of making design decisions.
The research presented in this paper has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 644055.