[doap-interest] Extending DOAP for software packaging

[Shadi Abou-Zahra]

Hi Zack,

On 9.1.2012 19:42, Zack Williams wrote:
> On Jan 9, 2012, at 04:53 , Shadi Abou-Zahra wrote:
>> Maybe somewhat similar to this request we found that DOAP is great for describing software development projects but less so for instances of actual software (builds).
>
> I'm thinking rather than builds or version numbers be the smallest unit of version differentiation, the different branches in a VCS repo could be.
>
> Imagine a large project with multiple people working on it, and there being version tags (v1, v2, etc.) , feature branches (stable, testing, development) that could all be specified individually, then run through automated builds/testing.
>
> Maybe it would be best to add additional elements added to the schema that specify a specific commit, branch, tag, etc.
>
> Alternatively an URL scheme might make sense - for example:
>
>   https://github.com/edumbill/doap.git#commit=9af487e57a
>
> Could specify the specific commit "9af487e57a".  Ideally VCS creators or website would pick up on this and support it in their tools as well.

This makes sense.

However, the use case I am talking about is to describe the software as 
such rather than software projects; for example such software listings:
  - <http://www.w3.org/WAI/ER/tools/complete>


>> The currently draft W3C Evaluation and Report Language (EARL) proposes earl:Software that is a sub-class of doap:Project, to describe a piece of software instance:
>> -<http://www.w3.org/TR/EARL10-Schema/#Software>
>
> Interesting.  On first glance EARL looks similar to TAP ( http://testanything.org/ ) with output similar in verbosity to Schematron.

Yes. We believe you can express TAP output in EARL but EARL also covers 
some more context around the actual test results (for example about the 
software that is involved in the testing or being tested etc).


>> It would be better to have this be directly part of the DOAP Schema rather than in EARL or other secondary schemas.
>
> Agreed.
>
> If anything, it might be better to make the existing versioning more fine grained.  For example, splitting a version into major/minor/bugfix as individual elements, rather than just having a string that would need to be parsed, although doing anything like that opens a whole can of worms with the wide variety of numbering schemes out there.

For EARL we did not find a need to have different versioning. We use 
existing DOAP terms and think they adequately describe software. The 
issue is really the definition of doap:Project versus the requested 
doap:Software (rather than the current earl:Software work-around).


Thanks,
   Shadi

> Thanks,
> Zack

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Activity Lead, W3C/WAI International Program Office
Evaluation and Repair Tools Working Group (ERT WG)
Research and Development Working Group (RDWG)