[doap-interest] Stuff I'd like to model

[balbinus]

Hi (it's me once more :)

(>: Edd Dumbill, >>: Shaun McCance)
 
> On Wed, 2004-07-28 at 16:46 -0500, Shaun McCance wrote:
> > Branches
> > I'd like to be able to specify branches of programs, not so much in 
> > the CVS sense (though I'll come to that later), but the "series of 
> > related releases" sense.  So 2.6.0, 2.6.1, and 2.6.2 would all be on 
> > the 2.6 branch.
You can use, I think, doap:name (that would correspond to its rdfs:label (a
name of sth). For example : <doap:name>2.0 series</doap:name> (for Apache
project).

> > 2.6.2 could very well be released after 2.7.0.  This is common 
> > practice.
doap:created gives precisions about this.

> > What's on a branch might vary from project to project (i.e.
> > bug fixes only, features but no incompatibilities, etc.).
That looks like a (doap|dc):description.

> <release>
>   <Version>
>     <name>2.6</name>
>     <created>2004-08-05</created>
>     <revision>2.6.1</revision>
>   </Version>
> </release>
> 
> Perhaps the problem here is that Version/name might be better named 
> Version/branch?
Well, doap:name is "A name of something.". So it's correct :) But is its
rdfs:domain (doap:Project) correct? I'm not at all a guru of RDFS :)
Furthermore, some projects have version _names_ (Debian GNU/Linux, eg).

> > Aggregate Projects
> > [...]
> > I'd like to say that the GNOME 2.7.x series contains the 
> > gnome-desktop 2.7.x series, the metacity 2.8.x series, the yelp 
> > 2.6.x series, etc.
> 
> So maybe we want a subclass of Project (say, MetaProject?) which is 
> able to say, for each subproject;
> 
> <contains>
>   <Project>
>     <homepage rdf:resource="..." />
>     <release>
>       <Version>
>         <name>2.6</name>
>       </Version>
>     </release>
>     <rdfs:seeAlso rdf:resource="..." /> <!-- ptr to subproject DOAP -->
>   </Project>
> </contains>
Or, shorter, something like <contains rdf:resource="URL-of-the-sub-DOAP" />?

> > Branches and Tags, CVS Style
> > It's common practice to tag releases in CVS.  So to get Yelp 2.6.1, 
> > you can check out the yelp module with the tag YELP_2_6_1.  I'd like 
> > to give the CVS tag for any particular doap:Version.  Along the same 
> > lines, it's common for continued development of a branch/series (as 
> > above) to happen on a branch in CVS.  So I'd like to give the CVS 
> > branch for continued development of a series.
> 
> Am thinking that an extension cvs: namespace might be handy to get 
> this sort of metadata in.  I mean to write up guidelines on extending 
> DOAP in this sort of way.
Norman Walsh has something of a CVS RDFS (http://nwalsh.com/rdf/cvs). It
seems it only contains CVS keywords (revision, etc), and no Tag. But that
could be an interesting inclusion in his RDFS :)

> > Documentation
> > DOAP provides doap:documenter, which is nice.  But it doesn't 
> > provide a whole lot of information about the documentation itself.  
> > Documentation can be a project in its own right, and I'd like to model
that.
> 
> Right.  And where it's available in HTML online, it'd be nice for DOAP 
> to link to it in a meaningful way.
What about doap:doc (or doap:help), following the model of doap:wiki & Co?
 
> > Nautilus
> > doesn't have its own documentation.  Rather, the documentation for 
> > it is in the GNOME User Guide, which is shipped in gnome-user-docs.  
> > Even for projects that do ship their own documentation, I'd like to 
> > consider the documentation to be a subproject (as above), and link them.
> 
> Maybe this might be best solved by an extension namespace to deal with 
> documentation issues.  The subproject then may or may not be required.
> e.g. there are various HOWTOs which aren't official subprojects in any 
> way.
<doap:doc>
 <foaf:Document rdf:about="URL-of-the-doc-DOAP" /> </doap:doc>?

Vincent TABARD
http://www.balbinus.net
http://www.terratettofiorentino.com
http://www.fluorine-cms.net
http://www.radiopytagor.com
http://prgmti.balbinus.net
http://rdfpic.balbinus.net
http://www.sidar.org/wshoy/
http://www.bonjourlesmouettes.org