The perfectly-named DOAP (nominally Description Of A Project though the O and A are capitalized only to make the acronym homonymous with Homer Simpson's famous utterance) is an XML/RDF vocabulary to describe FOSS. Its authors claim that it "will meet the needs of project maintainers who find they must register their software at myriad Web sites, and for anyone seeking to exchange such data." A first draft of the DOAP terms define basics: project, version, repository, each of which are RDF classes.
- As in all RDF schemas, an RDF class is a type of resource, similar to the way that a class is a type of object in Java programming. Also, a RDF property is a relationship between one resource and either another resource or a literal value. IBM has a full explanation of RDF schemas.
 Version class
The DOAP version class "represents an instance of a software release."  Accordingly it would be better titled a software revision or software patch level in line with industry practices, as the "term:release" implies a range of other activities including marketing and so on.
Sadly the properties indicate a lack of integrity in the DOAP basic data structures:
- branch = A string indicating the branch of this version, such as stable, unstable, gnome24, or gnome26 (a hazard, such branches would need to be objects in themselves)
- name = A release name, such as Panther, which probably applies to many versions (an hazard, the correct approach would be to identify the intended release as a different object)
- created = Date of release in YYYY-MM-DD form without a time zone (an error).
- revision = Revision number of the release, such as 1.0, which should increment reliably so that multiple versions are not reported as identical revisions (another error as the version identity itself could easily contradict the revision if this is a property)
 Repository class
The DOAP:repository attempts to "describe source code repositories. In itself this is not very useful, so DOAP has four more concrete subclasses of repository, for the Subversion, BitKeeper, CVS, and GNU Arch source revision control systems." For each property, there is a mapping to the analogous concept in that system.
- "anon-root = Path of the root of the anonymously accessible repository
- module = Module name of source code within the repository
- browse = URL of Web browser interface to the repository
- location = Base URL of archive"
While this is at least abstracting across some systems in common use, it remains sloppy. Why a FOSS project would have any repository that is NOT anonymously accessible at least to read isn't clear, so anon-root seems simply redundant. Why the interface to browse it would differ from that or the base URL is also not clear. And again there's no implied discipline on module names even though such does exist for FOSS projects if only via GNU or LAMP conventions. These omissions are mystifying when you consider that "DOAP is restricted to describing public access versions of the repositories, which are read-only. This removes the need to codify access control information for the writeable repositories, thus simplifying DOAP without much penalty as participant developers will have other ways of discovering this information." So no abstractions for hard security (like gACL) are even supported, yet the namespace allows for that in implying there will or must be differences between a "base URL", "URL of web browser interface" and "root of the anonymous accessible repository" or root of other repositories. It would seem that DOAP's authors have simply not thought this through.
 Project class
The following list of properties is cited within the DOAP project class, and has similar problems. Among them, assuming that only one "wiki" and only one "mailing list" and one "programming-language would be associated with a project, use of absurd abbrevisions (like shortdesc), no clear association of the category with any particular ontology, and the use of "os" as if it meant something, and didn't require a more detailed specification of a compatible boot image for this software.
- name The main name of the project, by which it is known publicly
- shortname A short name of the project, most often used for filenames
- homepage URI of the project's homepage, associated only with this one project
- old-homepage URI of a project's past homepage, associated only with this one project
- created Date when the project was created, in YYYY-MM-DD form
- description Plain text description of a project; several sentences
- shortdesc A short plain text description of a project; eight or nine words
- category A URI denoting a category assigned to the project
- wiki URI of a Wiki attached to this project
- bug-database URI of a bug tracker or e-mail address to report bugs on the project
- screenshots URI of a Web page with screenshots of the project
- mailing-list URI of a mailing list attached to this project
- programming-language Programming language this project is implemented in or intended for use with
- os Operating system the project is limited to (omit if the project is not OS-specific)
- license URI of a license through which the project software is available
- download-page URI of the location where the project software can be downloaded
- download-mirror URI of a download mirror site
- repository A doap:Repository describing a source code repository for the project
- release A doap:Version describing a current release of the project's software
- maintainer A foaf:Person describing the project maintainer or leader
- developer A foaf:Person describing a developer on the project
- documenter A foaf:Person describing a contributor of documentation to the project
- translator A foaf:Person describing a contributor of translations to the project
- helper A foaf:Person describing a contributor to the project not otherwise described by the other properties" 
"Classes are labeled with capitalized terms, such as "Project" and "Person." This is a common but abusive convention in writing RDF vocabularies. Properties are written in lower case. English conventions, by contrast, use capitalization only for proper nouns and acronyms and avoid them like the plague they are for generic terms, on the grounds that genericity is relative. "The outer element of a DOAP document is <Project>" and the "<rdf:RDF> container" can omitted as "the description can be written with one outer node. The Friend-of-a-Friend (FOAF) vocabulary is used to describe people...The standard xml:lang attribute denotes the language of textual properties."
 attempt at reflexivity
The DOAP namespace is used to reflexively describe itself:
<Project xmlns="http://usefulinc.com/ns/doap#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <name>DOAP</name> <homepage rdf:resource="http://usefulinc.com/doap" /> <created>2004-05-04</created> <shortdesc xml:lang="en"> Tools and vocabulary for describing community-based software projects. </shortdesc> <description xml:lang="en"> DOAP (Description of a Project) is an RDF vocabulary and associated set of tools for describing community-based software projects. It is intended to be an interchange vocabulary for software directory sites, and to allow the decentralized expression of involvement in a project. </description> <maintainer> <foaf:Person> <foaf:name>Edd Dumbill</foaf:name> <foaf:homepage rdf:resource="http://usefulinc.com/edd" /> </foaf:Person> </maintainer> </Project>
 not ready for prime time
DOAP seems to suffer from the same confusions as FOAF. It is confused, internally inconsistent, and of no value to a developer at this time. Like most geek fetish projects it seems to be a mere excuse for "the crucial next step" which "is to establish a suite of tools for the creation and consumption of the vocabulary. If DOAP is to live up to its promise as an interchange vocabulary for software directories, then it needs some real-world deployment." This is totally wrong. It needs to be internally consistent and externally consistent at least with document repository and open configuration needs first.
 extend to automate software releases
That said, "it is plain that DOAP needs to be extended to cover software releases. Making release announcements is a major burden on software projects, and some way of automating this process would help maintainers." This would help to discipline the project considerably. For instance, it would become obvious that more than one "wiki" or "mailing list" is associated with a typical project. Also obvious that to have separate identities for a "version" object and "revision" property within that or "name" for that release level, is a disaster, as the marketing people happily use the same name for a wide range of releases, and the release may have a lot of revision numbers before it ends.
See extend DOAP to automate software releases where this goal is fully discussed.