Le jeudi 19 avril 2018, 00:05:01 CEST Christopher a écrit : [...] > > > Yeah. That's great, but as I pointed out, it's useless to do so if they > > > aren't utilized for any other purpose. > > > > As I keep saying, the DOAPs *ARE* used to build the p.a.o pages. > > Okay, okay. Sorry, Sebb. You're right. It does seem to still be in use for > building some portions of p.a.o. I just didn't see any evidence of that, > and could not find any documentation on *how* it is used to build them. perhaps I should just add that PMC RDF data files are used to build Committees pages: https://projects.apache.org/committees.html (Committee is a synonym here for PMC) and projects DOAP files are used to build Projects pages: https://projects.apache.org/projects.html
it's not so obvious since the difference between Committe and Project is not so obvious I'm happy to have some feedback on the documentation written, that I'm not sure many people read: I'll be happy to improve it given on the feedback > > You are right. I was mistaken. I had not spent enough time on the site to > understand how it is used, and it was not obvious to me that any > functionality was missing when the DOAP file was missing. Sorry for the > misunderstanding on my part. > > After some more time spent on the site, I was able to see some portions > which don't work if the DOAP is missing. Specifically, I can now see that > it is used for grouping projects by language, by category, and listing > releases (which is the information I was asking for, and which would be > useful to add to [2], along with any other way it is used that I did not > observe.) > > I do think it is preferred that p.a.o get release information from > reporter.a.o instead... it would make maintaining DOAP simpler, and reduce > the burden on developers to maintain a duplicate dataset. I confess that Branko's remark about "Semantic Web aficionados appear to have vanished into the space between microservices" seems relevant... the idea behind using some universal format, and not just Apache internal tooling, was appealing: everything that is done magically by internal tooling has drawbacks. But for sure, the release part is the most hard to manually maintain part. > Thank you for your persistence in educating me. I did eventually get there. > Sorry if my confusion and ignorance caused any unnecessary strife. :) It's good to have feedback and interest, even if the interest contains criticism: it's constructive feedback Regards, Hervé --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
