Difference between revisions of "project"

From Microformats Wiki
Jump to navigation Jump to search
(consolidated existing formats work, added process-consistent headings, requests for creation of respective pages)
Line 16: Line 16:
== Related microformats ==
== Related microformats ==
* [[hCalendar]] for timelines and milestones (?) and TODOs
* [[hCalendar]] for timelines and milestones (?)
* [[hToDo]] TODOs
* Ressources
* Ressources
** [[hCard]] for attending/participating" people (staff)
** [[hCard]] for attending/participating" people (staff)

Revision as of 17:46, 16 January 2008


Per the microformats The microformats process. Start always with number one.

The Project-*

  1. *examples
  2. *formats
  3. *brainstorming
  4. hProject
  5. faq
  6. *implementations
Please read The microformats process first, before creating new pages!

Please note : This spec is under construction. For now, it is only a dump of ideas. Work to develop a format to describe the various aspects of a public project like open-source software or other kinds of artistic distributions. One if its primary intent is to allow robots to automatically classify projects in a freshmeat manner by browsing the web.

ZimbaTm 08:31, 12 Jan 2008 (PST)

real world examples

Please document in project-examples per The microformats process.

existing formats

Please document in project-formats.

Related microformats


Please document in project-brainstorming.

markup sample

<div class="project" id="urn:uuid:233f6e5d-2ad2-4b7e-a3fe-1b90ef2fef57">
  <img class="logo" src="..." />
  <span class="name">Microformats</span>
  <span class="desc">An initiative to extract common patterns from POSH</span>

  <h1>Some informations</h1>
  <a href="http://microformats.org/" rel="home">The primary home page of the project.</a>
  <a href="..." rel="source">Here you can find its source code.</a>
  <a href="..." rel="release">Get the releases.</a>
  <-- Every hCard is looked as a participant [including venues? ] -->

  <h1>Project's tags</h1>
    <li class="tag">open</li>
    <li class="tag">format</li>
    <li class="tag">standard</li>

CSS selection specification

A good way to describe the structure, is to look at it trough the view of CSS selectors. Designers sometimes need wrappers, which makes it hard to keep a strict structure. If you used jQuery, you know what I mean.

.project[@id] : is an UUID (see http://ietf.org/rfc/rfc4122.txt).
A unique identifier for the project.
It is used to resolve name clashes.
.project .name : the content describes the project name.
Should not appear more that one time per project.
.project IMG.logo : the src is a link to the logo.
Can have different sizes with by adding "low | mid | high" classes.
.project A[@rel=home] : a project's home page
.project A[@rel=source] : a link to the project's source.
If it is a scm, it is generally solved by using different uris.
Like git:// or bzr:// or http+git://
.project A[@rel=release] : the linked pages contains file releases.
This page can contain hRelease microformat.
.project A[@rel=...] : many extensions can be imagined, like :
 "blog | wiki | parent-project | ..."
.project .tag : the content describes a project tag. You can
have as many as you wish.


  • Lots of discussion I guess, to satisfy different kinds of projects
  • Semantic approval of experts


Please, keep the format simple. Unlike hCard, it doesn't follow an existing standard, which permits to keep it simple. I'd much more prefer to develop sub-standards instead of being verbose. For example, the uuid:.. or scm:// ones.

Related ideas

  • Release: semantic description of a project release. Possible usages : automatic tracking and/or conversion for package managers, automatic platform/mirror selection for download managers.