project: Difference between revisions
DannyAyers (talk | contribs) |
(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) | ||
== | == real world examples == | ||
existing | 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 | ||
== | == 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
The Project-*
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.
- 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 and milestones (?) and TODOs
- Ressources
- hReview for debriefing
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.