Update 2004-12-26 - working with Benjamin Nowack on creating a merged set of terms, incorporating his Project Management vocabulary
Update 2004-07-24 - added DOAP profile (see Description of a Project)
Update 2004-05-07 - looks like I'm going to be needing this myself, so am in the process of revising - latest schema
This document specifies a vocabulary for describing projects independently of the project domain (e.g. software product development, fundraising, painting the garage). The intended architecture is primarily goal-oriented, that a project will consist of goals which may be broken down into subgoals and may be satisfied by completing a set of associated tasks. The vocabulary is constructed using the Resource Description Framework (RDF) and the Web Ontology Language (OWL). It may be used in conjunction with other RDF vocabularies such as FOAF or as an RSS 1.0 module. The schema is provided in RDF/XML (other syntaxes to follow). Its ontological definition is in the OWL DL sublanguage.
This is a work-in-progress, a practical application is being developed for evaluation of the vocabulary.
Please post comments here or mail me.
OWL Ontology - should be usable now, most terms are relatively stable though additional constraints (corresponding to the prose description below) are likely to be added.
text blocks in italics have just been copy & pasted from elsewhere, here for temporary reference while figuring out the definitions
Project management and issue tracking
A Project Management System
GoalList
Module
Task
TaskList
Project
Agent
Session
Environment
name
logo
goalType
version
hasGoal
taskType
priority
status
duration
submittedDate
startDate
targetDate
finishDate
dependsOn
isDependentOf
isHelpedBy
helps
hasAgent
owns
reporter
agentType
role
hasReport
The PRJ Project Vocabulary is intended for use with RDF tools for describing projects. The terms have been chosen such that they are general enough to represent elements of virtually any project. Projects are described as instances of RDF graphs.
The project vocabulary is primarily goal-oriented: a project will be described as a set of goals which correspond to elements of the project. These goals identify the purpose of each element, the way in which each goal is to be achieved will be described in terms of tasks. Individual goals and tasks may be broken into subgoals and subtasks, and each of these will be represented by a node (instance of a class) within the graph. The relationships between the goals and tasks will be represented by arcs (properties) between the nodes.
Each goal or task may be be further described using other terms from the vocabulary. The vocabulary lends itself to a methodology involving hierarchical decomposition, though it should be noted that the model supports interdependencies that fall outside of a strict hierarchy (the model is a graph, not a tree).
Within the hierarchical view, completion of the project as a whole can be seen as the root goal.
The goals described by this vocabulary may either be 'hard' in the sense that it is can easily be stated whether or not the goal has been achieved, or 'soft' where such a call is difficult or impossible to make (if the project was to climb a mountain, then a soft goal might be to do it safely). Soft goals are often things that can be measured (e.g. number of climbing injuries). Within the vocabulary a goal will be considered 'hard' if it is represented by an instance of the Goal class, rather than explicitly represented by an instance of the SoftGoal class.
Similarly there are two sets of properties that correspond to
hard and soft dependencies : dependsOn/isADependencyOf
are used where the relationship is 'hard', in other words a well-defined dependency
- if A dependsOn B then it is impossible to achieve A without first
achieving B. The 'soft' dependency relationships are represented using helps/isHelpedBy
and hurts/isHurtBy. These
terms are loosely defined, and whereas it may be possible to use the 'hard'
relationships to make decisions based on classical logic, the 'soft' relationships
may be of use where heuristics are applied.
Although many of the concepts have been lifted from the world of software project management, it should be emphasized that this is only one possible domain of application. It is anticipated that in the context of software project management this vocabulary will primarily be used in the early stages of requirements analysis.
In the context of software requirements specification, 'hard' goals correspond to functional requirements, 'soft' goals correspond to non-functional requirements, aspects such as usability, reliability, interoperability and scalability.
The XML namespace for this vocabulary is http://purl.org/stuff/project/ and the recommended prefix is prj.
In RDF/XML documents the following declaration should be used :
xmlns:prj="http://purl.org/stuff/project/"
the state of affairs that a plan is intended to achieve
(WordNet noun Goal, sense 1.)
A goal is a condition or state of affairs in the world that the stakeholders
would like to achieve. How the goal is to be achieved is not specified, allowing
alternatives to be considered.
A goal can be either a business goal or a system goal. A business goal express
goals regarding the business or state of the business affairs the individual
or organisation wishes to achieve. System goal expresses goals the target system
should achieve, which, generally, describe the functional requirements of the
target information system.
A softgoal is a condition or state of affairs in the world that the actor would like to achieve, but unlike in the concept of (hard) goal, there are no clear-cut criteria for whether the condition is achieved, and it is up to subjective judgement and interpretation of the developer to judge whether a particular state of affairs in fact achieves sufficiently the stated softgoal.
Each softgoal has a type, such as "minimizing memory utilization", and a topic, such as "system". The type qualifies the topic. Together they express a goal that needs to be achieved during the design process (i.e. "minimizing memory utilization in the system").
When NFR softgoals are refined to the extend that specific design techniques or options can be identified, these are expressed as "operationalizations" (soft) goals. They are shown as clouds with thick solid borders graphically). Softgoals may have additional impact on each other beyond those established through refinements. These "side effects" are called correlations and are shown as dotted line links. Arguments in support of (or to object to) goals or their contributions are "claims" softgoals and are shown as clouds with dotted line borders.
- a block of work containing Goals and Tasks
(WordNet noun Module, sense 4.)
- an activity (=Action) a specific piece of work
(WordNet noun Task, sense 2.)
A task specifies a particular way of doing something. When a task is specified
as a sub-component of a (higher-level) task, this restricts the higher-level
task to that particular course of action.
Tasks can also be seen as the solutions in the target system, which will satisfice
the softgoals (called operationalizations in NFR). These solutions provide operations,
processes, data representations, structuring, constraints and agents in the
target system to meet the needs stated in the goals and softgoals.
The sub-components of a task can be goal, task, resource, and softgoal.
(a bag of tasks)
(WordNet noun list, sense 1.)
- a specialization of Module to identify a complete unit
(WordNet noun project, sense 1.)
An actor is an active entity that carries out actions to achieve goals
by exercising its know-how. Graphically, an actor may optionally have a boundary,
with intentional elements inside.
(WordNet noun agent, sense 6.)
//entity
- a (time and/or agent and/or task ) delimited set of actions applied to a
module
(WordNet noun list, sense 3.)
(extension of isDefinedBy)
branchTag
The name of the Project/Goal
sbclass of rdf:label
(WordNet noun version, sense 2.)
(likely objects : Defect, Documentation, Patch, Feature, Enhancement...)
(Unassigned, Open, Resolved... - Live/Test?)
A Task Means_Ends Structure connects a task with the means (tasks) to achieve
it directly, which is a short hand form of one Task Decomposition Structure
and the related Goal Means_Ends Structure. See Figure2 as an example.
A Resource Means_Ends Structure connects a resource with the means (tasks) to
make it available, which is a short hand form of one <softgoal Contribution
Structure>.See Figure 3 as an example.
GRL DECOMPOSITON statement provides the ability to define what other elements need to be achieved or available in order for a task to perform.
A Task Decomposition Structure shows the essential components of a task, which include subtasks that must be performed, subgoals that must be achieved, resources that must be accessible, and softgoals that must be satisfied.
(Person, software tool...)
(Developer, Observer, QA...)
GRL (Goal-oriented Requirement Language) is a language for supporting goal-oriented modelling and reasoning of requirements, especially for dealing with non-functional requirements (NFRs). It is expressed in textual, graphic or XML notations. The mapping between GRL and PRJ takes place at the abstract model level.
There are three main categories of concepts: intentional elements, intentional relationships, and actors. Intentional elements of GRL map onto RDF classes in the PRJ schema, intentional relationships onto properties.
Intentional Elements
goal
maps directly onto prj:Goal
task
maps directly onto prj:Task
softgoal
maps directly onto prj:SoftGoal
belief
use http://purl.org/ibis#Argument
resource
use rdf:Resource
Intentional Relationships
The relationships of the GRL ontology map to properties in the PRJ vocabulary, although PRJ descriptions are less fine-grained than those of GRL. However, in many cases a one-to-one mapping will be achievable by taking into consideration the type of the subject and object of the statement/relationship.
means-ends
use prj:dependsOn
decomposition
use prj:dependsOn
contribution
use one or more of prj:dependsOn;
correlation
(side effects) as contribution
dependency
use prj:dependsOn with subject rdf:type prj:Agent and object rdf:type prj:Agent
Actors
map indirectly to prj:Agent; prj:agentType; prj:role; their possession of intentional elements expressed using prj:owns
The Project vocabulary described here only aims to provide a core set of terms. It is anticipated that both domain-specific (e.g. for software projects) and more generally applicable vocabularies will be used alongside the Project vocabulary. The following are likely candidates for general use.
Some of the terms in PV may map directly to (qualified) DC (elements/terms), and where appropriate equivalence relationships will be expressed in this schema. I'm not yet sure whether subclass/subproperty relationships will be appropriate. With a bit of luck a friendly DC'er might help me out...
@@TODO UPDATE There is significant crossover between this vocabulary and the work being done on calendaring at the W3C. The main schema referred to is hybrid (Michael Arick/Libby Miller), which draws on earlier work such as iCal. Because of its roots this schema is already pretty complex, so I decided to ignore it until I'd got this schema roughed out. A mapping is very desirable for information sharing, but I think it'll be easier to do this at a loosely-coupled equivalence level rather than using hybrid terms directly (or subclassing) for this schema. With a bit of luck a friendly calendarer might help me out...
...
W6 offers an easy way of augmenting the Project vocabulary by relating entities
based on simple descriptive relationships : who, what,
why, when, where and how.
This documentation and associated RDF Schema will be placed in the public domain under a Creative Commons license, with the usual software liability disclaimers. Reproduction as a whole or in part is permitted without restriction. The author would be grateful if the namespace advisory note is taken into consideration for any derivative work.
DOAP - Edd Dumbill, description of a (software) project (in RDF) notes (with outher related links)
Project members in RDF blogroll
MetaL - An XML based Meta-Programming language
Project Management XML Schema (PMXML) huge!
Bugzilla
Scarab
werkz
Maven
2004-05-07 : considerable revision of schema, minor additions to docs
2003-09-30 : added # to namespace
2003-06-12 : added SoftGoal; GoalList; hurts; isHurtBy; hasAvailability. owner modified to owns. general tidying up and descriptions added
2003-04-10 : added Environment; hasReport; branchTag; name; logo.
2003-02-10 : submittedDate added
2003-02-05 : added license note & namespace description
2003-01-30 : Initial public draft.