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)
Line 6: Line 6:
[[User:ZimbaTm|ZimbaTm]] 08:31, 12 Jan 2008 (PST)
[[User:ZimbaTm|ZimbaTm]] 08:31, 12 Jan 2008 (PST)


== Existing pattern ==
== real world examples ==
existing pattern for projects
Please document in [[project-examples]] per [[process]].
* [http://usefulinc.com/doap/ DOAP: Description of a Project] (software project-specific)
 
== 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://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]
* [http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique Program Evaluation and Review Technique]
Line 19: Line 22:
*** [[rel-payment]]
*** [[rel-payment]]
* [[hReview]] for debriefing
* [[hReview]] for debriefing
* [http://dannyayers.com:88/xmlns/hdoap/profile/index.xhtml hDOAP] is an unofficial microformat-like 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]


== possible code example ==
== brainstorming ==
Please document in [[project-brainstorming]].
 
=== markup sample ===


<pre><nowiki>
<pre><nowiki>
Line 44: Line 49:
</nowiki></pre>
</nowiki></pre>


== CSS selection specification ==
=== 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.
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.
Line 69: Line 74:


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

Revision as of 17:15, 16 January 2008

Project

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!

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 process.

existing formats

Please document in project-formats.

Related microformats

brainstorming

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

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.

to-do

  • Lots of discussion I guess, to satisfy different kinds of projects
  • 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

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