On 11 May 2015 at 13:21, Sergio Fernández <sergio.fernan...@redlink.co> wrote: > Hi, > > On Mon, May 11, 2015 at 1:13 PM, sebb <seb...@gmail.com> wrote: >> >> 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 >> "commons" >> This is then assumed to be the name of an RDF file in data_files/ >> > > Then such " assumption" is a custom patch, it' d need to be know by any > other tool. Therefore no external tool is able to process such data.
Agreed, but I suspect think that may not be the only assumption made by the XSL scripts. IMO it would be best to establish all the changes that need to be made in one hit rather than to have to keep asking PMCs to fix another aspect of their DOAPs. > >> > 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 >> files. This would mean adding a new script to create a basic PMC file. >> > > We can provides some infrastructure, either to validate or create whatever > in the right way. > > >> 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. >> > > FMPOV the cleanest approach would be to serve all that files from each web > site. Yes, that was my point. > >> Another aspect is that DOAP files are not useful in source/binary releases. >> > > We can workout a DOAP extension for such feature. I don't think that would be a good idea. If the DOAP file is part of the source release, how can it have the correct release date for the release it is part of? Also, source trees are duplicated in tags and branches; it's confusing to have multiple copies of a DOAP. The point is that DOAPs are meta data about a project and its releases. They are not data that is useful to the project code. > I just need time ;-) > > Cheers, > > -- > Sergio Fernández > Partner Technology Manager > Redlink GmbH > m: +43 6602747925 > e: sergio.fernan...@redlink.co > w: http://redlink.co
