project: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(consolidated existing formats work, added process-consistent headings, requests for creation of respective pages)
m (Reverted edits by Niuhaibiao (Talk) to last version by Crojecta)
 
(32 intermediate revisions by 5 users not shown)
Line 1: Line 1:
<h1>Project</h1>
<h1>Project</h1>
{{formatset|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.
'''Please note : This spec is under construction. For now, it is only a dump of ideas.'''
{{TOC-right}}
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.
'''View each individual page as the main page omits some content.'''
{{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)
[[User:ZimbaTm|ZimbaTm]] 08:31, 12 Jan 2008 (PST)


== real world examples ==
== Analysis of Examples (Based on 8 examples.)==
Please document in [[project-examples]] per [[process]].
 
=== 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 ==
== existing formats ==
Please document in [[project-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://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]
* [http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique Program Evaluation and Review Technique]


== Related microformats ==
== Related microformats ==
* [[hCalendar]] for timelines and milestones (?) and TODOs
* [[hCalendar]] for timelines, milestones, and to-do items
* Ressources
* Resources
** [[hCard]] for attending/participating" people (staff)
** [[hCard]] for participating people
** [[product]] for stuff(?)
** [[product]] for stuff(?)
*** [[rel-payment]]
*** [[rel-payment]]
Line 24: Line 47:


== brainstorming ==
== brainstorming ==
Please document in [[project-brainstorming]].


=== markup sample ===
== 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).


<pre><nowiki>
==== instructions ====
<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>
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 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>
* 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 sometimes 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).
<div class="projecta">
A unique identifier for the project.
<h3 class="fn">Germinating Seeds</h3>
It is used to resolve name clashes.
<p class="summary">
.project .name : the content describes the project name.
How to germinate seeds in potting mix.<br />
Should not appear more that one time per project.
</p>
.project IMG.logo : the src is a link to the logo.
<p class="vcard fn">Derek Lewis</p>
Can have different sizes with by adding "low | mid | high" classes.
<p>Published <abbr class="published" title="2009-03-28T09:30-11:00">28. Mar 2009</abbr></p>
.project A[@rel=home] : a project's home page
<img src="/img/seed.png" class="photo" width="100" height="100" alt="Seed"/>
.project A[@rel=source] : a link to the project's source.
<h4>Requirements</h4>
If it is a scm, it is generally solved by using different uris.
<ul class="requirement">
Like git:// or bzr:// or http+git://
<li>Container(s) (With drain holes)</li>
.project A[@rel=release] : the linked pages contains file releases.
<li>Seed(s)</li>
This page can contain hRelease microformat.
<li>Potting Mix</li>
.project A[@rel=...] : many extensions can be imagined, like :
<li>Fresh Water</li>
"blog | wiki | parent-project | ..."
<li>A Light Source</li>
.project .tag : the content describes a project tag. You can
</ul>
have as many as you wish.
<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>


== to-do ==
== 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
== Notes ==
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 ==
== 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.
* Release: 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.