www-site-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: DOAP format question
Date Mon, 11 May 2015 11:13:39 GMT
On 11 May 2015 at 07:46, Sergio Fernández <wikier@apache.org> wrote:
> 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.
> 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/data_files/commons.rdf

There is some special-case XSL code which does this conversion.
If the rdf:resource URL does not end in ".rdf", then the the http://
and .apache.org/ header and trailer are stripped off, leaving
This is then assumed to be the name of an RDF file in data_files/

I've no idea why the actual URL was not required - perhaps it was
thought that the data_files directory location might not be stable.
This was in the code before I got involved.

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

Changing it now would be very time-consuming and tedious.
However, if this were to be done, I suggest dropping the data_files
directory entirely and insisting that PMCs host their own PMC data
This would mean adding a new script to create a basic PMC file.

Another aspect of this is where the RDF files are stored.
These need to be under the control of the project, and it makes sense
to keep them under source control (SC).
However SC URLs tend to change, thus breaking the project build.
Therefore I suggest it would be best if the RDF files were stored
under the website URL - which is much less prone to change, and
redirects can deal with any required changes.
Website source is nowadays stored in SC anyway.

Another aspect is that DOAP files are not useful in source/binary releases.

> 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.
> Let me try to find some time to put some of these things in order to have a
> better overview...
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co

View raw message