While I'm packaging morla, I've found in the tarball tree a little XML file
named "doap.rdf", which turned out to be a DOAP file. An apt-file query
(on 'sid', i386) showed me that there are at least three packages which
install such files:
I haven't be found any quick way to search the Debian source archive for file
names, but Google Code Search provided me with a rough estimate of how
many DOAP files are around there, in tarballs and VCSs. There are several
dozens; what's most noteworthy, some of them belong to non-aforementioned
softwares included in Debian. Sadly enough, they appear to have very loose
conventions about naming (with respect to contents, at least a validator
exists, although currently only for any «pure DOAP, not DOAP in an RDF
Now, DOAP is of course an interesting thing from the semantic web. The Apache
Software Foundation supports it. An ITP bug has been filed for moap,
a project maintenance tool using DOAP files. There are DOAP generators,
maybe some converters, and so on. Info in these files are kind of like those
which one may find on e.g. Freshmeat about projects. doapspace.org
collects DOAP entries, mostly generated from Sourceforge updates...
So, I don't know how these files might be useful (as sources for information
on upstream projects, I guess). Anyway, I have some questions I'd like to see
answered, so I may do a better job (as a prospective maintainer).
1) Should we include DOAP files from upstream in packages? (always?)
2) If so, where? (usr/share/doc sounds OK if they are only provided for sake
of completeness, while IMVHO if we want them to be globally parsed and/or
indexed it would be good to have an ad-hoc hierarchy under e.g.
3) (related to the above question) Should they have uniform names? If so, in
what form? Should we distinguish between pure DOAP and «DOAP in an RDF
I know you will enlighten me. :-) Thanks.