[doap-interest] Project Dependencies

[balbinus]

Hi,

>My thoughts are more, what if a Project produces more than one type of
Release.  This is definitely more common.
You can indicate as much releases as you want, with different doap:name.

> We can probably just have different releases with different xml:lang
attribute.
Impossible. xml:lang describes a literal (a string, eg). You have to use
something like dc:language for this.

> 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.  
Why not :) I'm currently trying to define an RDF vocab for describing
mailing lists (see
http://bonjourlesmouettes.org/index.php/2004/09/29/102-mailing-list-descript
ion-rdf-vocabulary).

But I think that creating vocabs for describing Debian packages, JARS etc is
not in the scope of DOAP, and, imho, against DOAP's goal: creating a UNIFIED
vocabulary that can describe each and every project, wherever it comes from.

> 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
I think that the subproject issue is something we should address quickly,
everyone's asking for 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