project: Difference between revisions
m (Reverted edit of VanGore, changed back to last version by Tantek) |
(prev revert: there is no hToDo microformat. this edit: edited intro, add problem statement, scenarios section, move statement of intent accordingly, add process items to to-do, reword notes) |
||
Line 1: | Line 1: | ||
<h1>Project</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}} | |||
{{formatset|Project}} | {{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) | ||
Line 16: | Line 19: | ||
== Related microformats == | == Related microformats == | ||
* [[hCalendar]] for timelines | * [[hCalendar]] for timelines, milestones, and to-do items | ||
* | * Resources | ||
** [[hCard]] for | ** [[hCard]] for participating people | ||
** [[product]] for stuff(?) | ** [[product]] for stuff(?) | ||
*** [[rel-payment]] | *** [[rel-payment]] | ||
Line 27: | Line 30: | ||
=== markup sample === | === 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> | <pre><nowiki> | ||
Line 50: | Line 54: | ||
=== CSS selection specification === | === 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. | 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 74: | Line 79: | ||
== 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 == | == Notes == | ||
Please, keep the format simple. | 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. |
Revision as of 19:30, 16 January 2008
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.
The Project-*
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)
real world examples
Please document in project-examples per process.
existing formats
Please document in project-formats.
- DOAP: Description of a Project (software project-specific), hDOAP is a poshformat projection of DOAP into HTML, deployed at doapspace.org and cited in the GRDDL namespace doc
- RDF Project Vocabulary (general purpose)
- Program Evaluation and Review Technique
Related microformats
- hCalendar for timelines, milestones, and to-do items
- Resources
- hReview for debriefing
brainstorming
Please document in project-brainstorming.
markup sample
Note: this markup sample is not based on any project-examples implied schema, and therefore is an a priori brainstorm that is not suitable for a microformat.
<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
Note: this markup sample is not based on any project-examples implied schema, and therefore is an a priori brainstorm that is not suitable for a microformat.
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
- 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.