[doap-interest] Project Dependencies

[balbinus]

Hi,

> > >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?
More than one name??? Well, this is not an IFP, you can indicate more than
one without any risk... but it's strange.

> > >- group name space (organization URI)
> > doap:maintainer --> foaf:Organisation?
> > >- version number (<major>.<minor>.<increment>.<build>)
> > doap:version, afair
> 
> Is this doap:release?
Yep. doap:Version is a class :(

> 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
Why not. Using datatypes, I think.

> 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.
Well, that could be interesting to provide "words" for describing release
states (in the same way as WordNet).

> > >- 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
Didn't get a word, sorry... Anyway, if it's a widely used thing (.NET)...

> > >- 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.
What do you mean by "product"??? A version of the 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?
A doap:Project can't have (XML) children doap:Project... They are classes.

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