View source for project

<h1>Project</h1>
This is a page for tracking the effort to develop a project microformat for authors and publishers to markup public projects like open-source software or other kinds of artistic distributions.
{{TOC-right}}
{{formatset|project}}

== problem statement ==
=== scenarios ===
One of its primary intent is to allow robots to automatically classify projects in a freshmeat <!-- ? --> manner by browsing the web.
[[User:ZimbaTm|ZimbaTm]] 08:31, 12 Jan 2008 (PST)

== real world examples ==
Please document in [[project-examples]] per [[process]].

== existing formats ==
Please document in [[project-formats]].
* [http://usefulinc.com/doap/ DOAP: Description of a Project] (software project-specific), [http://dannyayers.com:88/xmlns/hdoap/profile/index.xhtml hDOAP] is a [[poshformat]] projection of DOAP into HTML, deployed at [http://doapspace.org doapspace.org] and cited in the [http://www.w3.org/2003/g/data-view GRDDL namespace doc]
* [http://dannyayers.com:88/xmlns/project/index.htm RDF Project Vocabulary] (general purpose)
* [http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique Program Evaluation and Review Technique]

== Related microformats ==
* [[hCalendar]] for timelines, milestones, and to-do items
* Resources
** [[hCard]] for participating people
** [[product]] for stuff(?)
*** [[rel-payment]]
* [[hReview]] for debriefing

== brainstorming ==
=Projecta=
Even though there are existing project formats, the projecta format {{must}} be developed because there is no established project format and it will enable decentralized development of projects.

== Format ==
=== In General ===
The projecta format is based on a set of fields common to numerous project sites and formats in use today on the web.  Where possible field names have been chosen based on those defined by the related [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] standards.

=== Schema ===
The projecta schema consists of the following:

* Projecta ('''<code>projecta</code>''')
** '''<code>version</code>'''. optional. text.
** '''<code>summary</code>'''. optional. text.
** '''<code>project</code>''' info. required. '''<code>fn</code>''' ('''<code>url</code>''' || '''<code>photo</code>''' )
** '''<code>author</code>'''. optional. '''[[hcard|hCard]]'''.
** '''<code>description</code>'''. optional. text with optional valid HTML markup.
** requirements. optional. text with optional '''<code>url</code>''' to products or other projects.
** steps. optional. text with valid HTML '''<code>ol</code>''' ('''<code>li</code>''') elements.
** tags. optional. keywords or phrases, using '''[[rel-tag]]''', each with optional rating.
** permalink. optional, using '''[[rel-bookmark]]''' and '''[[rel-self]]'''.

=== Field details ===
The fields of the projecta schema represent the following:

'''version''':: This optional field permits projecta publishers to specify a particular version of projecta that their content uses. This field is syntax compatible with, and thus reuses the semantics of "VERSION" as defined in vCard RFC2426 section "3.6.9 VERSION Type Definition".  The value of this field for this specification is "0.1".

'''summary''':: This optional field serves as a title for the project itself.

'''project info''':: This required field {{must}} have at a minimum the name  However, when using item info subproperties ("fn", "url", "photo"), they {{must}} be nested <em>inside</em> the item element.

'''author''':: The optional field specifies the person who authored the project.  If the author is specified, an hCard representing the author {{must}} be provided.
The projecta format is intended to be used in conjunction with MediaWiki which will require a username to submit a new project. The username will be represented with an hCard.

'''description''':: This optional field contains the full text representing the written opinion of the author.  The field {{may}}  include valid HTML markup (e.g. paragraphs).  User agents {{should}} preserve any markup.

'''requirements''':: This optional field contains the requirements of the project. The field {{may}} include links to products or other projects.

'''steps''':: Steps are represented using an ordered list of tasks required to complete the project. Represented as an ordered list with list elements.

'''tags''':: Tags are represented using a list of keywords or phrases (using the [[rel-tag]] microformat for each individual keyword or phrase tag) that the author associates with the project.

'''permalink''':: This optional field is a URL for the projecta.  In addition to using the <code><a href></code> tag for this field, the attribute <code>rel="self bookmark"</code> {{must}} be used to indicate that the hyperlink is a permalink for the project itself.  If the hyperlink already contains a <code>rel</code> attribute, then the values <code>self</code> and <code>bookmark</code> {{must}} be included among the space-separated set of values in the attribute.  Indexers {{may}} treat the permalink of a project as a unique ID in order to identify and collate the same project from multiple sources (such as indexing a page multiple times).  The permalink {{may}} also be used to indicate or imply the origin of the project. Authors {{may}} use the classname of "permalink" on the element representing the permalink.

The following field names have been reused from the [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] microformats: <code>version, summary, fn, url, photo, description, tags, permalink</code>.  In addition, items and authors described by hCards {{may}} contain any hCard field.  The rel value "self" has been reused from the [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html Atom 1.0 specification].


=== markup sample ===
<strong>Note: this markup sample is not based on any [[project-examples]] implied schema, and therefore is an <em>a priori</em> brainstorm that is not suitable for a microformat.</strong>

<pre><nowiki>
<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>
  <ul>
    <li class="tag">open</li>
    <li class="tag">format</li>
    <li class="tag">standard</li>
  </ul>
</div>
</nowiki></pre>

=== CSS selection specification ===
<strong>Note: this markup sample is not based on any [[project-examples]] implied schema, and therefore is an <em>a priori</em> brainstorm that is not suitable for a microformat.</strong>

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.

<pre><nowiki>
.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.
</nowiki></pre>

== to-do ==
* [[project-examples]]
* [[project-formats]]
* Lots of discussion I guess, to satisfy different kinds of projects
* Semantic approval of experts

== Notes ==
Please, keep the format simple. The current brainstorms above don't follow an existing standard (existing standards must first be documented in [[project-formats]] before proceeeding). It is preferable to re-use and develop minimal modules rather than being verbose. Are these bad or good 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.