project: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(Changed spec to follow rfc4122)
m (Reverted edits by Niuhaibiao (Talk) to last version by Crojecta)
 
(41 intermediate revisions by 8 users not shown)
Line 1: Line 1:
<h1>hProject</h1>
<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}}
{{TOC-right}}
'''View each individual page as the main page omits some content.'''
{{formatset|project}}


'''Please note : This spec is under construction. For now, it is only a dump of ideas.'''
== 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)


hProject is an open and simple format to describe the various aspects of a public project like open-source software or other kinds of artistic distributions. One if it's primary intent is to allow robots to automatically classify projects in a freshmeat manner by browsing the web.
== Analysis of Examples (Based on 8 examples.)==


== Let's start by an example ==
=== Common practical project fields ===
* fn (100%)
* summary (100%)
* author (50%)
* instructions (100%)
* requirement (50%)
* published (50%)
* duration (25%)
* tags (25%)


<pre><nowiki>
=== Common abstract project fields ===
<div class="project" id="urn:uuid:233f6e5d-2ad2-4b7e-a3fe-1b90ef2fef57">
* fn (100%)
  <img class="logo" src="..." />
* summary (75%)
  <span class="name">Microformats</span>
* author (50%)
  <span class="desc">An initiative to extract common patterns from POSH</span>
* due (50%)
* goal (25%)
* duration (25%)
 
== existing formats ==
Please document in [[project-formats]].
 
* [http://hyperdata.org/xmlns/project/ A vocabulary for describing projects] (primarily goal-oriented)
* [http://usefulinc.com/doap/ DOAP: Description of a Project] (software project specific)
** [http://hyperdata.org/xmlns/hdoap/profile/ hDOAP] - previous [[poshformat|microformat-like]] effort
* [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 ==
 
== Format ==
=== In General ===
The projecta format documents practical (how-you-can-do) projects.  Where possible field names have been chosen based on those defined by the related [[hcard|hCard]], [[hatom|hAtom]], [[hcalendar|hCalendar]], and [[hrecipe|hRecipe]].
 
=== Schema ===
The projecta schema consists of the following elements:
 
* '''projecta'''
** '''''fn'''''. required. text. the formatted name of the project. re-used from [[hCard]].
** '''''summary'''''. optional. text. re-used from [[hCalendar]].
** '''''author'''''. optional. 1 or more. re-used from [[hAtom]] using [[hCard]].
** ''published''. optional. re-used from [[hAtom]]. [experimental]
** ''tag''. optional. 1 or more. re-used from [[rel-tag]]. [experimental]
** ''photo''. optional. 1 or more. using any element containing a URL, such as IMG. re-used from [[hCard]]. [experimental]
** ''requirement''. optional. text with optional valid (x)HTML markup.
** ''instructions''. optional. text with optional valid (x)HTML markup. re-used from [[hRecipe]].
** '''''duration'''''. optional. 1 or more. text (see [[ISO-31-1]] duration brainstorming). re-used from [[hCalendar]].
 
=== Field details ===
The fields of the projecta schema represent the following:
 
==== fn ====
 
The title of a single project. The formatted name of what the projecta documents.
 
* The element is identified by class name <code>fn</code>.
* A projecta {{must}} include a <code> fn </code>.
* The element {{must}} follow the conventions outlined in [[hCard]].
 
==== summary ====
 
The summary provides a short introduction to or an accompanying statement about the project.
 
* The element is identified by the class name <code>summary</code>.
* A projecta {{may}} include a <code>summary</code>.
* The element {{must}} follow the conventions outlined in [[hCalendar]].
 
==== author ====
 
The person who authored the project.
 
* The element is identified by class name <code>author</code>.
* A projecta {{may}} include one or more <code>author</code> elements.
* The contents of the element {{must}} follow the conventions outlined in [[hCard]].
 
==== published ====
 
The date the project was published.
 
* The element is identified by the class name <code>published</code>.
* A projecta {{may}} include a <code>published</code> date.
* The element {{must}} follow the conventions outlined in [[hAtom]].
* The [[datetime-design-pattern]] {{should}} be used to encode the published datetime.
* The element is considered ''experimental'' and may be removed from the final specification.
 
==== tag ====
 
A keyword indicating a subject or an important aspect of the project like it's main requirement, type of project etc.
 
* The element is identified by class name <code>tag</code>.
* A projecta {{may}} include one or more <code>tag</code> elements.
* The element {{must}} follow the conventions outlined in [[rel-tag]].
 
==== photo ====
 
Accompanying image.
 
* The element is identified by the class name <code>photo</code>.
* A projecta {{may}} include one or more photo elements.
* The element {{should}} use an &lt;img&gt; element.
* The element {{may}} use any other element that contains a URL, such as &lt;a&gt; or &lt;object&gt;, but it is not recommended.
* The contents of the element {{must}} follow the conventions outlined in [[hCard]].
 
==== requirement ====
 
Describes one or more requirements of the project.
 
* The element is identified by the class name <code>requirement</code>.
* A projecta {{must}} include one or more <code>requirement</code>s.
* The field {{may}} include valid HTML markup (e.g. a list of requirements).
 
==== instructions ====


  <h1>Some informations</h1>
Documents the instructions required to complete the project.
  <a href="http://microformats.org/" rel="home">The primary home page of the project.</a>
  <a href="..." rel="source">Here you can find it's source code.</a>
  <a href="..." rel="release">Get the releases.</a>
  <-- Every hCard is looked as a participant -->


  <h1>Project's tags</h1>
* The element is identified by the class name <code>instructions</code>.
  <ul>
* A projecta {{may}} include a <code>instructions</code> element.
    <li class="tag">open</li>
* The field {{may}} include valid HTML markup e.g. paragraphs or a list of steps.
    <li class="tag">format</li>
    <li class="tag">standard</li>
  </ul>
</div>
</nowiki></pre>


== CSS selection specification ==
==== duration ====


A good way to describe the structure, is to look at it trough the view of css selectors. Designers some times need wrappers, which makes it hard to keep a strict structure. If you used jQuery, you know what I mean.
The time it takes to complete the project described by the projecta. Multiple duration fields can be used to denote time taken per instruction.
* The element is identified by the class name <code>duration</code>.
* A projecta {{may}} include one or more <code>duration</code>s.
* The element {{must}} follow the conventions outlined in [[hCalendar]].


<pre><nowiki>
<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.
<div class="projecta">
.project .name : the content describes the project name. Should not appear more that one time per project.
<h3 class="fn">Germinating Seeds</h3>
.project IMG.logo : the src is a link to the logo. Can have different sizes with by adding "low | mid | high" classes.
<p class="summary">
.project A[@rel=home] : a project's home page
How to germinate seeds in potting mix.<br />
.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://
</p>
.project A[@rel=release] : the linked pages contains file releases. This page can contain hRelease microformat.
<p class="vcard fn">Derek Lewis</p>
.project A[@rel=...] : many extensions can be imagined, like : "blog | wiki | parent-project | ..."
<p>Published <abbr class="published" title="2009-03-28T09:30-11:00">28. Mar 2009</abbr></p>
.project .tag : the content describes a project tag. You can have as many as you wish.
<img src="/img/seed.png" class="photo" width="100" height="100" alt="Seed"/>
<h4>Requirements</h4>
<ul class="requirement">
<li>Container(s) (With drain holes)</li>
<li>Seed(s)</li>
<li>Potting Mix</li>
<li>Fresh Water</li>
<li>A Light Source</li>
</ul>
<h4>Instructions</h4>
<ol class="instructions">
<li>Loosen and dampen the potting mix.</li>
<li>Fill 2/3 of each container(s) with potting mix.</li>
<li>Put seed(s) in container with potting mix.</li>
<li>Sprinkle a few drops of water over of the seed(s). (Remember to repeat this once potting mix becomes dry.)</li>
<li>Place container under light source.</li>
</ol>
</div>
</nowiki></pre>
</nowiki></pre>


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


== Author's notes ==
== 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.
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 pages ==
 
* [[hRelease]] : semantic description of a project release. Possible usages : automatic tracking and/or conversion for package managers, automatic platform/mirror selection for download managers.

Latest revision as of 23:08, 14 January 2010

Project

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.

View each individual page as the main page omits some content.

Per the microformats process. Start always with number one.

The project-*

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

problem statement

scenarios

One of 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)

Analysis of Examples (Based on 8 examples.)

Common practical project fields

  • fn (100%)
  • summary (100%)
  • author (50%)
  • instructions (100%)
  • requirement (50%)
  • published (50%)
  • duration (25%)
  • tags (25%)

Common abstract project fields

  • fn (100%)
  • summary (75%)
  • author (50%)
  • due (50%)
  • goal (25%)
  • duration (25%)

existing formats

Please document in project-formats.

Related microformats

brainstorming

Format

In General

The projecta format documents practical (how-you-can-do) projects. Where possible field names have been chosen based on those defined by the related hCard, hAtom, hCalendar, and hRecipe.

Schema

The projecta schema consists of the following elements:

  • projecta
    • fn. required. text. the formatted name of the project. re-used from hCard.
    • summary. optional. text. re-used from hCalendar.
    • author. optional. 1 or more. re-used from hAtom using hCard.
    • published. optional. re-used from hAtom. [experimental]
    • tag. optional. 1 or more. re-used from rel-tag. [experimental]
    • photo. optional. 1 or more. using any element containing a URL, such as IMG. re-used from hCard. [experimental]
    • requirement. optional. text with optional valid (x)HTML markup.
    • instructions. optional. text with optional valid (x)HTML markup. re-used from hRecipe.
    • duration. optional. 1 or more. text (see ISO-31-1 duration brainstorming). re-used from hCalendar.

Field details

The fields of the projecta schema represent the following:

fn

The title of a single project. The formatted name of what the projecta documents.

  • The element is identified by class name fn.
  • A projecta MUST include a fn .
  • The element MUST follow the conventions outlined in hCard.

summary

The summary provides a short introduction to or an accompanying statement about the project.

  • The element is identified by the class name summary.
  • A projecta MAY include a summary.
  • The element MUST follow the conventions outlined in hCalendar.

author

The person who authored the project.

  • The element is identified by class name author.
  • A projecta MAY include one or more author elements.
  • The contents of the element MUST follow the conventions outlined in hCard.

published

The date the project was published.

  • The element is identified by the class name published.
  • A projecta MAY include a published date.
  • The element MUST follow the conventions outlined in hAtom.
  • The datetime-design-pattern SHOULD be used to encode the published datetime.
  • The element is considered experimental and may be removed from the final specification.

tag

A keyword indicating a subject or an important aspect of the project like it's main requirement, type of project etc.

  • The element is identified by class name tag.
  • A projecta MAY include one or more tag elements.
  • The element MUST follow the conventions outlined in rel-tag.

photo

Accompanying image.

  • The element is identified by the class name photo.
  • A projecta MAY include one or more photo elements.
  • The element SHOULD use an <img> element.
  • The element MAY use any other element that contains a URL, such as <a> or <object>, but it is not recommended.
  • The contents of the element MUST follow the conventions outlined in hCard.

requirement

Describes one or more requirements of the project.

  • The element is identified by the class name requirement.
  • A projecta MUST include one or more requirements.
  • The field MAY include valid HTML markup (e.g. a list of requirements).

instructions

Documents the instructions required to complete the project.

  • The element is identified by the class name instructions.
  • A projecta MAY include a instructions element.
  • The field MAY include valid HTML markup e.g. paragraphs or a list of steps.

duration

The time it takes to complete the project described by the projecta. Multiple duration fields can be used to denote time taken per instruction.

  • The element is identified by the class name duration.
  • A projecta MAY include one or more durations.
  • The element MUST follow the conventions outlined in hCalendar.
<div class="projecta">
	<h3 class="fn">Germinating Seeds</h3>
	<p class="summary">
		How to germinate seeds in potting mix.<br />
	</p>
	<p class="vcard fn">Derek Lewis</p>
	<p>Published <abbr class="published" title="2009-03-28T09:30-11:00">28. Mar 2009</abbr></p>
	<img src="/img/seed.png" class="photo" width="100" height="100" alt="Seed"/>
	<h4>Requirements</h4>
	<ul class="requirement">
		<li>Container(s) (With drain holes)</li>
		<li>Seed(s)</li>
		<li>Potting Mix</li>
		<li>Fresh Water</li>
		<li>A Light Source</li>
	</ul>
	<h4>Instructions</h4>
	<ol class="instructions">
		<li>Loosen and dampen the potting mix.</li>
		<li>Fill 2/3 of each container(s) with potting mix.</li>
		<li>Put seed(s) in container with potting mix.</li>
		<li>Sprinkle a few drops of water over of the seed(s). (Remember to repeat this once potting mix becomes dry.)</li>
		<li>Place container under light source.</li>
	</ol>
</div>

to-do

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.