community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: DOAP format question
Date Tue, 12 May 2015 06:47:39 GMT
Le lundi 11 mai 2015 08:46:41 Sergio Fernández a écrit :
> Hi sebb,
> 
> On Tue, May 5, 2015 at 7:08 PM, sebb <sebbaz@gmail.com> wrote:
> > > What I can already say is that I do not understand what
> > 
> > https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/
> > data_files> 
> > > aim to represent.
> > 
> > This is the default location for the PMC data [1] files which provide
> > data about the PMC.
> > A single such file may be referenced by multiple DOAPs.
> > E.g. all the Commons components refer to the same PMC data file.
> 
> I do understand how DOAP is being used, and I guess it has been wrong from
> the very beginning.
I fear that's true :/
let's analyze what is wrong and fix it :)

> 
> Taking commons-lang as example, they currently have:
> 
>   <Project rdf:about="http://commons.apache.org/lang/">
>     <asfext:pmc rdf:resource="http://commons.apache.org/"/>
>   </Project>
> 
> which does not really link (in RDF) to the file
> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/da
> ta_files/commons.rdf
> 
> RDF is a directly-label graph data model that uses URIs as names. Therefore
> the URI you put as as value of a property has a meaning, you should be able
> to directly fetch it, but not having such implicit rules where files a
> located in a svn. I guess apply that would mean a major restructuration of
> the current DOAP data, but that's something I can help to do to all PMCs.
> 
> Beside that issue on linking, I have come to the conclusions that asfext
> actually have the sense of two things:
> 
> * asfext:pmc is the property that links a project with its PMC
> * asfext:PMC should be a class for referring to PMCs
> 
> And that completely valid, but the tooling should know the difference and
> not just try to fix wrong data.
while working on it, I think I found one root cause: we're not clear about 
TLPs (with PMCs) vs software (often called "projects" too, but that have 
releases)

it seems https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files
is about TLPs/PMCs
and "classical" DOAP files written by people are about softwares that are done 
by TLPs/PMCs

We have a TLPs/PMCs authoritative source of information: that is committee-
info.txt
I used it as main source of data for
https://projects-new.apache.org/json/foundation/tlps.json
The only informations in tlps.json that do not come from committee-info.txt 
are:
- committers list (committee-info.txt only lists PMC members, LDAP gives 
committers)
- description of the TLPs: I'm still looking which could be the authoritative 
information source

for more details, the parsing code is here:
http://svn.apache.org/viewvc/comdev/projects.apache.org/scripts/import/parsecommittees.py?view=markup

I think we could generate an authoritative DOAP url for TLPs from committee-
info.txt
then give instructions to projects to update their software DOAP files to point 
to these reference TLPs DOAP files

this would:
- fix issues regarding standard DOAP/RDF semantics
- be easy to explain

I can generate tonight http://projects-new.apache.org/doap/tlp/ as a POC for 
https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files replacement

notice: from TLP and PMC, I prefer to talk about TLP, since the TLP has a PMC 
+ a homepage, committers, and other attributes

WDYT?

Regards,

Hervé

> 
> Let me try to find some time to put some of these things in order to have a
> better overview...


Mime
View raw message