<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.10">
</HEAD>
<BODY>
<BR>
<BR>
On Wed, 2004-09-29 at 12:30, balbinus wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>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></FONT></PRE>
</BLOCKQUOTE>
<BR>
I think what I was musing over is more the relationships between Project and a Releases, and Project and Sub-Projects.<BR>
My thoughts are more, what if a Project produces more than one type of Release. This is definitely more common.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>> > >- 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)...</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
We can probably just have different releases with different xml:lang attribute.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>
> > >- 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?</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
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.<BR>
<BR>
Currently, the definition has a property named doap:release. I think I'd prefer to see doap:Release as a class with properties:<BR>
- name<BR>
- short name<BR>
- description<BR>
- date of release<BR>
- version<BR>
- version quality<BR>
- pre build dependencies <BR>
- run time dependencies<BR>
- and other stuff taken from debian's package meta data, such as can replace, replaces, etc<BR>
<BR>
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 <BR>
<A HREF="http://jakarta.apache.org/commons/releases/versioning.html">http://jakarta.apache.org/commons/releases/versioning.html</A><BR>
<BR>
If Release is a class we can also do something similar for Release, so we can have Debian Vocab, Java JAR vocab, etc.<BR>
<BR>
What are thoughts on how to manage and define all these one-offs from DOAP? <BR>
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. <BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>
> > >- 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.</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
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 ;-)<BR>
<BR>
I was thinking more on the lines of a property doap:subProject that is ranged by <A HREF="http://usefulinc.com/ns/doap#Project">http://usefulinc.com/ns/doap#Project</A><BR>
<BR>
- Mike<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>
Cordialement,
Vincent TABARD</FONT>
<A HREF="http://www.balbinus.net"><U>http://www.balbinus.net</A>
<A HREF="http://www.terratettofiorentino.com">http://www.terratettofiorentino.com</A>
<A HREF="http://www.fluorine-cms.net">http://www.fluorine-cms.net</A>
<A HREF="http://www.radiopytagor.com">http://www.radiopytagor.com</A>
<A HREF="http://prgmti.balbinus.net">http://prgmti.balbinus.net</A>
<A HREF="http://rdfpic.balbinus.net">http://rdfpic.balbinus.net</A>
<A HREF="http://www.sidar.org/wshoy/">http://www.sidar.org/wshoy/</A>
<A HREF="http://www.bonjourlesmouettes.org">http://www.bonjourlesmouettes.org</A>
<A HREF="http://doap-fr.org">http://doap-fr.org</U></A>
<FONT COLOR="#737373">
_______________________________________________
doap-interest mailing list
doap-interest@lists.usefulinc.com</FONT>
<A HREF="http://lists.usefulinc.com/mailman/listinfo/doap-interest"><U>http://lists.usefulinc.com/mailman/listinfo/doap-interest</U></I></A></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>