Software Projects Description Re: [uf-discuss] Potential Microformats

[Danny Ayers]

I could have sworn I mailed this or the dev list about hDOAP [1] , but
I can't find anything substantial in the archives, probably forgot the
cc...anyhow basically it's a way of describing software projects in
HTML, based on DOAP [2] which could potentially become a microformat
(according to microformats.org conventions). I've done a GRDDL profile
and XSLT from DOAP to hDOAP and vice versa (though it looks like I've
broken the XSLT somewhere, will fix asap).

My original motivation was to be able to author and publish DOAP data
in XHTML, and in the process check out the viability of a) deriving a
microformat from an existing RDF vocabulary; b) the GRDDL mechanism
for interpreting XHTML as RDF. DOAP has a fairly constrained RDF/XML
syntax and transformation from DOAP to XHTML is possible, so being
able to render DOAP documents in a HTML browser is a bonus.

I didn't follow microformats.org process, though I do believe some of
the key prerequisites have been fulfilled.

On 05/10/06, Karl Dubost <karl at w3.org> wrote:

> * Use Case Scenarios?
> * Benefits for the End Users?

Edd Dumbill did an impressive amount of research for DOAP, check in
particular the goals [3] and the write-ups at developerWorks (linked
from the sidebar at [2]). He put a lot of effort into finding out what
people were already doing to describe projects, and came up with a set
of terms that he felt gave good coverage. DOAP has seen a substantial
amount of adoption, which validates Edd's approach - an approach which
I believe is generally in line with the research side of the
microformats process. Edd's paved the cowpaths, they just need a
little HTML varnish.

As Stephen noticed, what is lacking from a technical point of view is
a refactoring of various constructs to existing microformats. A XMDP
profile would also be very desirable, though this could largely be
derived from DOAP's RDF schema (as documented at [4]).

I believe what's lacking from a process point of view is mainly a few
cycles through this list ;-)

One key question would be whether to go with DOAPs coverage, or to
expand/modify/contract it. Because of Edd's prior work, my personal
opinion would be to stick to that scope, it also has the advantage of
easy interop with existing DOAP deployment.

Incidentally I've still got looking at the task description/scheduling
kind of project description on my personal to-do list, appropriately
enough starting with iCal's TODO (as suggested by Tantek).

Cheers,
Danny.

[1] http://purl.org/stuff/hdoap/profile
[2] http://usefulinc.com/doap
[3] http://usefulinc.com/doap/goals
[4] http://www-128.ibm.com/developerworks/xml/library/x-osproj3/

-- 

http://dannyayers.com