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. > > 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. > Another aspect is that DOAP files are not useful in source/binary releases. > We can workout a DOAP extension for such feature. 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
