project: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (Reverted edits by Niuhaibiao (Talk) to last version by Crojecta)
 
(21 intermediate revisions by 3 users not shown)
Line 2: Line 2:
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.
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}}
{{formatset|project}}


Line 9: Line 10:
[[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.)==


=== Freshmeat.net ===
=== Common practical project fields ===
Description of the software project
* fn (100%)
* http://freshmeat.net
* summary (100%)
* author (50%)
* instructions (100%)
* requirement (50%)
* published (50%)
* duration (25%)
* tags (25%)


** full project name (This is the publicly visible project name.)
=== Common abstract project fields ===
** short project name (This will be used to generate a /projects/<shortname>/ URL for your project.)
* fn (100%)
** full description
* summary (75%)
** short description
* author (50%)
** name of author
* due (50%)
** email address
* goal (25%)
** branch name
* duration (25%)
** branch description
** license
** homepage
** version
** release focus
 
=== 43things.com ===
* http://43things.com
How I did a project
 
** goal title
** last words (One sentence summary.)
** how
** lessons
** resources
 
== Analysis of Examples ==
 
=== Common review fields ===
* project (name/title|URL(s)|image)
* author (name|email|URL)
* summary


== 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] (broken link)
 
* [http://dannyayers.com:88/xmlns/project/index.htm RDF Project Vocabulary] (general purpose) (broken link)
* [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]


Line 60: Line 47:


== brainstorming ==
== 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 ===
=== Schema ===
The projecta schema consists of the following:
The projecta schema consists of the following elements:


* Projecta ('''<code>projecta</code>''')
* '''projecta'''
** '''<code>version</code>'''. optional. text.
** '''''fn'''''. required. text. the formatted name of the project. re-used from [[hCard]].
** '''<code>summary</code>'''. optional. text.
** '''''summary'''''. optional. text. re-used from [[hCalendar]].
** '''<code>project</code>''' info. required. ('''<code>url</code>''' || '''<code>photo</code>''' )
** '''''author'''''. optional. 1 or more. re-used from [[hAtom]] using [[hCard]].
** '''<code>author</code>'''. optional. '''[[hcard|hCard]]'''.
** ''published''. optional. re-used from [[hAtom]]. [experimental]
** '''<code>description</code>'''. optional. text with optional valid HTML markup.
** ''tag''. optional. 1 or more. re-used from [[rel-tag]]. [experimental]
** requirements. optional. text with optional '''<code>url</code>''' to products or other projects.
** ''photo''. optional. 1 or more. using any element containing a URL, such as IMG. re-used from [[hCard]]. [experimental]
** steps. optional. text with valid HTML '''<code>ol</code>''' ('''<code>li</code>''') elements.
** ''requirement''. optional. text with optional valid (x)HTML markup.
** tags. optional. keywords or phrases, using '''[[rel-tag]]''', each with optional rating.
** ''instructions''. optional. text with optional valid (x)HTML markup. re-used from [[hRecipe]].
** permalink. optional, using '''[[rel-bookmark]]''' and '''[[rel-self]]'''.
** '''''duration'''''. optional. 1 or more. text (see [[ISO-31-1]] duration brainstorming). re-used from [[hCalendar]].


=== Field details ===
=== Field details ===
The fields of the projecta schema represent the following:
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".
==== 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 ====


'''summary''':: This optional field serves as a title for the project itself.
The date the project was published.


'''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.
* 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.


'''author''':: The optional field specifies the person who authored the project.  If the author is specified, an hCard representing the author {{must}} be provided.
==== tag ====
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.
A keyword indicating a subject or an important aspect of the project like it's main requirement, type of project etc.


'''requirements''':: This optional field contains the requirements of the project. The field {{may}} include links to products or other projects.
* 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]].


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


'''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.
Accompanying image.


'''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 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]].


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].
==== requirement ====


Describes one or more requirements of the project.


=== markup sample ===
* The element is identified by the class name <code>requirement</code>.
<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 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 ====
<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.
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>


Line 154: Line 177:
* 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. 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 ==
== 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.