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