[doap-interest] Project Dependencies

Mike Stanley mstanley at mstanley.net
Fri Oct 1 14:29:12 BST 2004 


On Wed, 2004-09-29 at 12:30, balbinus wrote:

> 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.


I think what I was musing over is more the relationships between Project
and a Releases, and Project and Sub-Projects.
My thoughts are more, what if a Project produces more than one type of
Release.  This is definitely more common.


> > > >- 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)...


We can probably just have different releases with different xml:lang
attribute.


> 
> > > >- 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?


Again, I'm thinking more about the separation of the "Project" and the
"Release".  Where release can be a binary distribution, source
distribution, documentation/white paper, specification, anything really
that is the outcome of work done by a Project.  I see Project more as a
Collaborative Group.

Currently, the definition has a property named doap:release.  I think
I'd prefer to see doap:Release as a class with properties:
- name
- short name
- description
- date of release
- version
- version quality
- pre build dependencies 
- run time dependencies
- and other stuff taken from debian's package meta data, such as can
replace, replaces, etc

I think it makes sense to make Version a class, and allow groups define
their own version vocabulary to use in this property, such as 
http://jakarta.apache.org/commons/releases/versioning.html

If Release is a class we can also do something similar for Release, so
we can have Debian Vocab, Java JAR vocab, etc.

What are thoughts on how to manage and define all these one-offs from
DOAP?  
Here's an idea:   DOAPParts.  ---   What I mean by one-off's are special
vocabs for Release, Version, Mail Lists, etc.  A lot of these vocabs
don't already exist, and it would make sense to define a common set of
them along with the core DOAP Vocabulary.  So DOAP would define a
Project to have define release property, and we can have a collection of
DOAParts, that define DebianRelease vocab etc.  


> 
> > > >- 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.


Sorry about the mix-up in terminology, I'm only about waist deep in RDF
at this point --- getting deeper every day though and loving it ;-)

I was thinking more on the lines of a property doap:subProject that is
ranged by http://usefulinc.com/ns/doap#Project

- Mike


> 
> 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
> 
> 
> 
> _______________________________________________
> doap-interest mailing list
> doap-interest at lists.usefulinc.com
> http://lists.usefulinc.com/mailman/listinfo/doap-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.usefulinc.com/pipermail/doap-interest/attachments/20041001/4b8d0272/attachment.html

More information about the doap-interest mailing list