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 <[EMAIL PROTECTED]> 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 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
