[doap-interest] Project Dependencies

[Mike Stanley]

What's going on Vincent (et. al.) ...

> >Any interest in something like this becoming part of DOAP?  Has there been
> any work or any thoughts in this area?   
> Sure. This has yet been discussed on the list... No decision taken :)

Well.  More than happy to help get there...

DOAP currently is used to describe the metaphysical "project".  I'm
interested in using the DOAP vocabulary to describe the pyhsical builds/
resources produced by the project.  Maybe there is a 1-1 between the
two, but perhaps there is a 1-n relationship.  What do you think?  Does
it make sense to introduce something like - doap:product or
doap:resource ?  If they can be identified with a unique uri, then a
dependency list can contain references to other doap projects' products.

> 
> >Here is my thoughts on an initial list -
> >- unique name for the resource/package
> doap:name

doap:shortname as well.  These would make sense.  What if a project has
more than one byproduct?  

> >- group name space (organization URI)
> doap:maintainer --> foaf:Organisation?
> >- version number (<major>.<minor>.<increment>.<build>)
> doap:version, afair

Is this doap:release?  It would be nice to enforce
<major>.<minor>.<increment>.<build>  number formats in this.  I know
every project is different, but if this is enforced, it does allow for
some flexibility in dependencies, such as v1.2.*.* contracts

> >- version quality (pre-alpha | alpha | beta | rc X | final)
> mm... sounds interesting :) (although everyone will find other stages... I
> personally do use greek letters when I want to delay releases :)

i think version quality can be any string truthfully (unlike my argument
for stricter version number).  I think it may be important when
describing a project product.  Perhaps an empty version quality can
signal a final release.  Everything else is up to the project.

> >- description
> doap:description
> >- culture
> ???

the term is a .NET thing.  Basically it is for creating product release
of different internationalization.  In the GAC,  Assembly strong names
are created with name, version, culture, signature.  culture is
optional, but it allows you to create different products for different
internationalization values.  The GAC provides support for determining
the best suited assembly based on the current localization.  

I'm not 100% sold on this, but i can see how it can be helpful in
creating different build flavors

> >- package check sum
> Sorta doap:package_sha1sum...

yeah something like that.  

> >- package contents
> >   - name
> >   - checksum
> >   - description
> Well... What would the typical use case be?

I think this would be helpful in (1) describing the contents of a
project product / product dependency.  (2) determining a project
dependencies, in situations where you don't have a wonderful
self-describing DOAP file :-).  

For example, when I build Java projects, at times I run into missing
classes problems.  Sometimes these are self describing, other times I
have to dig around for a while to find the missing jar.  It would be
usefully if I could search for the jar, and retrieve the containing
product and parent project.

> >- dependencies
> doap:dependsOn --> rdf:resource="..."?

YES!!  The more I think about it the more I think it makes sense for a
project to have a product(s).
doap:product
  - name*
  - short name*
  - version*
  - version quality
  - dependsOn - rdf:resource="doapURI#product"

  *can be derived from doap:project

But then again it also makes sense to say a project is a product. 
Currently can a doap:project have children doap:project elements?

> 
> I'm personally very interested in this dependences field :)

Definitely.  I think some great things can come of it.


> 
> Cordialement,
> 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
> http://doap-fr.org