Re: Project Visualization Tool...

[Hervé BOUTEMY]

Le samedi 18 avril 2015 10:55:00 Shane Curcuru a écrit :
> LOL, below.
> 
> I highly recommend separating the model from the views, so that we can
> efficiently enable our volunteer's energy here to actually accomplish
> something valuable.
+1

> 
> So let's work on stuff to do that excites us, but remember to keep the
> technical problems focused on what this PMC believes we can truly create
> and maintain going forward.
> 
> Don't worry about everything at once.  Just focus on separate bits:
> 
> - Method to scrape source data from our various definitive or even not
> completely definitive but very close places (txt files, websites, LDAP)
> 
> - Model and data source that actually holds info about committer lists
> and project metadata.  I'm betting Daniels' projects-new does this very
> well already.
+1 it's a perfect starting point: just need to document and continue to 
improve
then I started by documenting what are the current information sources used 
for generating projects-new.a.o json files:
see https://projects-new.apache.org/json/foundation/ and 
http://svn.apache.org/viewvc/comdev/projects.apache.org/scripts/README.txt?view=markup

> 
> --
> - Stable API to get at that model.  Would be really nice if we did this
> just once, so that people working above here don't interfere with people
> working below here.
> --
+1

Since there are multiple information sources for TLPs/PMCs/committers, I think 
I will consolidate to avoid what's currently happenning: the projects.js (ie 
one visualization) contains a lot of code to consolidate the multiple 
information sources
If the consolidation is done server side, in the generation scripts, it will 
be easier to use for projects.js and any other tool wanting to do other future 
visualizations

> 
> - Visualizations.  There's lots of different stuff to do here, and I
> think it'd be super helpful if everyone just did something they want,
> and then show us the code.
+1

> 
> Sure, there's lots of "what is important" to focus on, but I for one
> would love to see real examples of all the cool visualization libraries
> out there, and I know a couple folks already use some of them.
> 
> - UI additions for the projects-new/projects websites, which are
> featured at the top level of a.o.  I.e., this is our "projects
> directory", how can we better lead people who arrive there at what they
> want to know?
at the moment, I'm not trying to add any new UI, but improve the consistency 
of displayed data, since current state is not really consistent: some PMCs are 
not displayed, probably because they have not provided any DOAP file. But even 
without DOAP file, we have a lot of data to display for a TLP, most of what we 
display for a TLP (ie a project that does not have any subproject)

I think we really have some data model problem here regarding what is a 
"project's DOAP file": sometimes, a project is a PMC, sometimes a project is a 
deliverable, more like what is called in projectsnew.a.o a "sub-project"

if you look at https://projects-new.apache.org/projects.html?pmc, typical 
cases for that are:
- Incubator: there is the "the Incubator project", displayed without DOAP file 
since the incubator has special source info, and many sub-projects which 
provide DOAP files
- Commons: there is no "Commons' DOAP file", then no TLP... on sub-project is 
quasi randomly chosen... Common's DOAP file, if it existed would not release 
anything, it"s a pure "organizational" project
- Ant: there is an Ant DOAP file that represent the TLP and the main released 
artifact

I chose Commons, but it could have been HttpComponents or Logging Services, or 
Lucene (Lucene have been very clear that there is a "Lucene core" sub-
project), Web Services, Axis, Xalan, Xerces, XML Graphics, Attic, Creadur, DB, 
jUDDI, Tcl

I chose Ant, but it could have been Velocity, MINA, Directory, HTTP Server, 
MyFaces, Tomcat


> 
> - (future) UI additions for *other* places.  It would be awesome, for
> example, to provide a tiny scriptlet that any project could inject in
> their website that displays a "see also" menu.  That would link to a
> specific URL on projects.a.o that would say "hey, you came from
> Cassandra, here are: -other big data projects, -other projects in Java,
> -other projects with the same committers... etc." as a service.
> 
> - Shane

I'll continue tonight on this
Any help appreciated

Regards,

Hervé

RE: DOAP format question

[neera.x.singh]

Hi 

Can anyone give any hint of implementing decision tree in pig?

Thanks
Neera
-Original Message-
From: Hervé BOUTEMY [mailto:herve.bout...@free.fr] 
Sent: 05 May 2015 11:37
To: sebb; Sergio Fernández
Cc: dev@community.apache.org; ASF Site-Dev
Subject: Re: DOAP format question

Le mardi 5 mai 2015 01:05:31 sebb a écrit :
> > OK, but that's because whoever code the XSLT decided to be defensive 
> > to such interpretation.
> 
> If you read back in this thread you will see that I did this in order 
> to support both asfext:PMC and asfext:pmc.
> 
> > But that does not mean is right.
> 
> The code is right in the sense that it works with the input files that 
> are provided.
+1
that's a temporary workaround that we should try to not need any more in the 
future

[...]

> >> Also if it is possible to validate that the various RDF files are 
> >> correct according to the formal definitions.
> >> PMCs could then submit their files for checking.
> > 
> > I think we can discuss that infrastructure for the new site. I'm 
> > happy to help. Python provides the required libraries. I'll open a 
> > thread, probably tomorrow.
> 
> I think there needs to be a way for PMCs to check their RDF files 
> against the formal definitions.
> For example, a CGI script that accepts the URL of a file.
+1
I tried W3C checker, but as it is only a syntax checker, it checked only 
syntax, not references to the namespace and I couldn't find any other useful 
tool :(

Other tools to make effective use of the DOAP files would be useful too: but I 
completely agree that the first priority seems to have a more complete checker

Regards,

Hervé

> 
> > Cheers,
> > 
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 6602747925
> > e: sergio.fernan...@redlink.co
> > w: http://redlink.co

This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

Re: DOAP format question

[Hervé BOUTEMY]

Le mardi 5 mai 2015 01:05:31 sebb a écrit :
> > OK, but that's because whoever code the XSLT decided to be defensive to
> > such interpretation.
> 
> If you read back in this thread you will see that I did this in order
> to support both asfext:PMC and asfext:pmc.
> 
> > But that does not mean is right.
> 
> The code is right in the sense that it works with the input files that
> are provided.
+1
that's a temporary workaround that we should try to not need any more in the 
future

[...]

> >> Also if it is possible to validate that the various RDF files are
> >> correct according to the formal definitions.
> >> PMCs could then submit their files for checking.
> > 
> > I think we can discuss that infrastructure for the new site. I'm happy to
> > help. Python provides the required libraries. I'll open a thread, probably
> > tomorrow.
> 
> I think there needs to be a way for PMCs to check their RDF files
> against the formal definitions.
> For example, a CGI script that accepts the URL of a file.
+1
I tried W3C checker, but as it is only a syntax checker, it checked only 
syntax, not references to the namespace
and I couldn't find any other useful tool :(

Other tools to make effective use of the DOAP files would be useful too: but I 
completely agree that the first priority seems to have a more complete checker

Regards,

Hervé

> 
> > Cheers,
> > 
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 6602747925
> > e: sergio.fernan...@redlink.co
> > w: http://redlink.co

Captcha on Apache mirror

[Niclas Hedhman]

I just tried to download Maven and randomly selected a download mirror;
http://apache.petsads.us/maven/maven-3/3.3.3/binaries/apache-maven-3.3.3-bin.tar.gz

But get presented with a captcha, and I think that is not expected/allowed
since it might break automated tools.

Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: DOAP format question

[sebb]

On 4 May 2015 at 20:50, Sergio Fernández  wrote:
>
>
> On Mon, May 4, 2015 at 9:04 PM, sebb  wrote:
>>
>> > The term must be used exactly in the same way it is defined by the
>> > namespace/vocabulary/ontology, otherwise won't be processed as expected.
>>
>> Theoretically, but not in this case.
>>
>> The processing is defined by XSL files that were manually created.
>> So whatever the files are coded to expect is what will work.
>> This may or may not be the same as the definition.
>>
>> In fact at present the XSL files have been coded to accept both
>> asfext:PMC and asfext:pmc.
>> Only one of these can be correct in terms of the formal definition.
>
>
> OK, but that's because whoever code the XSLT decided to be defensive to such
> interpretation.

If you read back in this thread you will see that I did this in order
to support both asfext:PMC and asfext:pmc.

> But that does not mean is right.

The code is right in the sense that it works with the input files that
are provided.

My point was that the formal definition does not affect how the XSL files work.
All that matters is that the XSL file agrees with what is in the input files.
They could use asfext:XyZ provided that the XSL files were coded to expect that.

Nor does the formal definition affect validation of the input RDF
files otherwise there would not be conflicting references in the RDF
files, and we would not be having this discussion.

>>
>> The problem is that it is not clear what the formal definition is.
>
> No, the formal definition is clear at the ns file:
> http://projects.apache.org/ns/asfext#pmc
>>
>>
>> It would help to know what the formal definition of the asfext
>> namespace actually means.
>
>
> Ok, let's try to put it eas. This is the definition from the namespace (rdf
> vocabulary):
>
> http://projects.apache.org/ns/asfext#pmc";>
>   http://projects.apache.org/ns/asfext#"; />
>   PMC
>   ASF Project Management
> Committee
>   http://www.w3.org/2000/01/rdf-schema#Literal"; />
>rdf:resource="http://www.w3.org/2000/01/rdf-schema#label"; />
>   http://usefulinc.com/ns/doap#"; />
> 
>
> That means:
>
> * the exactURI  (or abbreviated as
> asfext:pmc if the prefix declaration is available) defines the property
> name, exactly "pmc", other syntactic version would not match the formal
> definition.
> * the label is just the human-readable label of the property, can't be use
> as property
> * comment is the same, just a comment to be read
> * subproperty means that the value of the property has a specialized meaning
> over the general purpose label
> * domain is the type of objects that can use that property, in this case
> doap:Project instances
> *  range defines the values in ca take, int his case a literal, a basic
> type, such as string or int
>
> And that's more of less the semantics behind such definition of the
> property. Hope it helps to understand.

Yes, that is useful.

>>
>> Also if it is possible to validate that the various RDF files are
>> correct according to the formal definitions.
>> PMCs could then submit their files for checking.
>
>
> I think we can discuss that infrastructure for the new site. I'm happy to
> help. Python provides the required libraries. I'll open a thread, probably
> tomorrow.

I think there needs to be a way for PMCs to check their RDF files
against the formal definitions.
For example, a CGI script that accepts the URL of a file.

> Cheers,
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co

Re: DOAP format question

[Sergio Fernández]

On Mon, May 4, 2015 at 9:04 PM, sebb  wrote:

> > The term must be used exactly in the same way it is defined by the
> > namespace/vocabulary/ontology, otherwise won't be processed as expected.
>
> Theoretically, but not in this case.
>
> The processing is defined by XSL files that were manually created.
> So whatever the files are coded to expect is what will work.
> This may or may not be the same as the definition.
>
> In fact at present the XSL files have been coded to accept both
> asfext:PMC and asfext:pmc.
> Only one of these can be correct in terms of the formal definition.
>

OK, but that's because whoever code the XSLT decided to be defensive to
such interpretation. But that does not mean is right.


> The problem is that it is not clear what the formal definition is.
>

No, the formal definition is clear at the ns file:
http://projects.apache.org/ns/asfext#pmc

>
> It would help to know what the formal definition of the asfext
> namespace actually means.
>

Ok, let's try to put it eas. This is the definition from the namespace (rdf
vocabulary):

http://projects.apache.org/ns/asfext#pmc";>
  http://projects.apache.org/ns/asfext#"; />
  PMC
  ASF Project Management
Committee
  http://www.w3.org/2000/01/rdf-schema#Literal"; />
  http://www.w3.org/2000/01/rdf-schema#label"; />
  http://usefulinc.com/ns/doap#"; />


That means:

* the exactURI  (or abbreviated
as asfext:pmc if the prefix declaration is available) defines the property
name, exactly "pmc", other syntactic version would not match the formal
definition.
* the label is just the human-readable label of the property, can't be use
as property
* comment is the same, just a comment to be read
* subproperty means that the value of the property has a specialized
meaning over the general purpose label
* domain is the type of objects that can use that property, in this case
doap:Project instances
*  range defines the values in ca take, int his case a literal, a basic
type, such as string or int

And that's more of less the semantics behind such definition of the
property. Hope it helps to understand.


> Also if it is possible to validate that the various RDF files are
> correct according to the formal definitions.
> PMCs could then submit their files for checking.
>

I think we can discuss that infrastructure for the new site. I'm happy to
help. Python provides the required libraries. I'll open a thread, probably
tomorrow.

Cheers,

-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co

Re: DOAP format question

[sebb]

On 4 May 2015 at 19:37, Sergio Fernández  wrote:
> RDF can be serialized as XML, but the XML tool chain is not well suitable to
> process RDF. That's what a meant when I early commented I was happy to
> contribute proper DOAP/RDF infrastructure to projects-new.a.o.
>
> Back to the current issues... see my comments inline.
>
> On Mon, May 4, 2015 at 7:51 PM, sebb  wrote:
>>
>> On 4 May 2015 at 18:00, Hervé BOUTEMY  wrote:
>> > I'm not a RDF expert: if someone with more knowledge on this can join,
>> > it
>> > would be really useful
>> >
>> > But apart from seeing that most of the documentation was talking about
>> > pmc
>> > instead of PMC [1] (I just had to fix 1 place), I was convinced that the
>> > correct case is lowercase when reading asfext definition [2]
>> > once again, I'm not an expert then could misinterpret the content, but I
>> > read
>> > http://projects.apache.org/ns/asfext#pmc";> as a
>> > definition of pmc field, in lowercase
>>
>> Perhaps; I don't know either.
>> It's a bit odd that the original code used PMC rather than pmc.
>
>
> The term must be used exactly in the same way it is defined by the
> namespace/vocabulary/ontology, otherwise won't be processed as expected.

Theoretically, but not in this case.

The processing is defined by XSL files that were manually created.
So whatever the files are coded to expect is what will work.

This may or may not be the same as the definition.

In fact at present the XSL files have been coded to accept both
asfext:PMC and asfext:pmc.
Only one of these can be correct in terms of the formal definition.

The problem is that it is not clear what the formal definition is.

>>
>> Also PMC is an abbreviation. RDF is also an abbreviation, and note
>> that the XML tag is , not .
>>
>> It looks like namespaces (i.e. rdf, asfext) are lower-case, but
>> classes/properties (?) may be upper (rdf:RDF), lower (foaf:name) or
>> mixed case (foaf:Person).
>
>
> That's the best practice, yes: classes in UpperCamelCases, and properties in
> lowerCamelCase.
>
> The root element  is a special case, not a regular term, but part
> of the RDF/XML serialization.
>
> Hope that helps.

It would help to know what the formal definition of the asfext
namespace actually means.

Also if it is possible to validate that the various RDF files are
correct according to the formal definitions.
PMCs could then submit their files for checking.

> Cheers,
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co

Re: DOAP format question

[Sergio Fernández]

RDF can be serialized as XML, but the XML tool chain is not well suitable
to process RDF. That's what a meant when I early commented I was happy to
contribute proper DOAP/RDF infrastructure to projects-new.a.o.

Back to the current issues... see my comments inline.

On Mon, May 4, 2015 at 7:51 PM, sebb  wrote:

> On 4 May 2015 at 18:00, Hervé BOUTEMY  wrote:
> > I'm not a RDF expert: if someone with more knowledge on this can join, it
> > would be really useful
> >
> > But apart from seeing that most of the documentation was talking about
> pmc
> > instead of PMC [1] (I just had to fix 1 place), I was convinced that the
> > correct case is lowercase when reading asfext definition [2]
> > once again, I'm not an expert then could misinterpret the content, but I
> read
> > http://projects.apache.org/ns/asfext#pmc";> as a
> > definition of pmc field, in lowercase
>
> Perhaps; I don't know either.
> It's a bit odd that the original code used PMC rather than pmc.
>

The term must be used exactly in the same way it is defined by the
namespace/vocabulary/ontology, otherwise won't be processed as expected.


> Also PMC is an abbreviation. RDF is also an abbreviation, and note
> that the XML tag is , not .
>
> It looks like namespaces (i.e. rdf, asfext) are lower-case, but
> classes/properties (?) may be upper (rdf:RDF), lower (foaf:name) or
> mixed case (foaf:Person).
>

That's the best practice, yes: classes in UpperCamelCases, and properties
in lowerCamelCase.

The root element  is a special case, not a regular term, but part
of the RDF/XML serialization.

Hope that helps.

Cheers,


-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co

Re: DOAP format question

[sebb]

On 4 May 2015 at 18:00, Hervé BOUTEMY  wrote:
> I'm not a RDF expert: if someone with more knowledge on this can join, it
> would be really useful
>
> But apart from seeing that most of the documentation was talking about pmc
> instead of PMC [1] (I just had to fix 1 place), I was convinced that the
> correct case is lowercase when reading asfext definition [2]
> once again, I'm not an expert then could misinterpret the content, but I read
> http://projects.apache.org/ns/asfext#pmc";> as a
> definition of pmc field, in lowercase

Perhaps; I don't know either.
It's a bit odd that the original code used PMC rather than pmc.

Also PMC is an abbreviation. RDF is also an abbreviation, and note
that the XML tag is , not .

It looks like namespaces (i.e. rdf, asfext) are lower-case, but
classes/properties (?) may be upper (rdf:RDF), lower (foaf:name) or
mixed case (foaf:Person).

>
> since I was working on projects-new.a.o, I completely forgot to try to
> generate the current projects.a.o to check that the change didn't break
> anything: sorry, I'll try it tonight

Already done.
Check the output; I think it works OK for both now.

> one question: where is the cron log of the effective run?

/home/apsite/wrkdir/projects

> Regards,
>
> Hervé
>
>
> [1] http://projects.apache.org/docs/pmc.html
>
> [2] http://projects.apache.org/ns/asfext
>
> Le lundi 4 mai 2015 01:39:45 sebb a écrit :
>> XPath nodes are case-sensitive;  is not the same as
>> .
>>
>> The change from PMC to pmc has broken some of the reports - the PMC
>> name is missing from most of the entries listed in
>> http://projects.apache.org/indexes/pmc.html.
>>
>> I don't know which case is correct, but there are currently RDF files
>> in project repos which use PMC rather than pmc.
>> These files are not easy to fix, as each project has to be asked to do them.
>>
>> I can probably fix the scripts to check for both, but that is quite messy.
>>
>> It would be better to use the "correct" case setting throughout
>> (whatever that is).
>> It looks like the original xsl file only used PMC, however a fairly
>> early revision started using pmc and continued using PMC.
>> Perhaps there was always an issue with some of the reports?
>>
>> Until the correct setting is established, there's no point asking
>> projects to fix their RDF files.
>>
>> I don't know if there is a formal description of the syntax anywhere.
>>
>> On 14 April 2015 at 00:00, Hervé BOUTEMY  wrote:
>> > ok, it seems I can update the source, then I did it
>> >
>> > I suppose this will be published in the next site content generation...
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le dimanche 12 avril 2015 04:41:22 Hervé BOUTEMY a écrit :
>> >> Hi,
>> >>
>> >> I'm working on http://projects-new.apache.org/ , which makes me dig into
>> >> ASF DOAP conventions
>> >>
>> >> And I found something that I think is a bug: on
>> >> http://projects.apache.org/docs/pmc.html , half of the page explains
>> >> about
>> >> asfext:PMC in uppercase, while the other half is about asfext:pmc in
>> >> lowercase
>> >>
>> >> AFAIK, everybody is using asfext:pmc, in lowercase
>> >>
>> >> Can you confirm that it is in lowercase? Then fix the page, that is
>> >> causing
>> >> a little bit of confusion?
>> >>
>> >> Thanks in advance,
>> >>
>> >> Hervé
>

Re: DOAP format question

[Hervé BOUTEMY]

I'm not a RDF expert: if someone with more knowledge on this can join, it 
would be really useful

But apart from seeing that most of the documentation was talking about pmc 
instead of PMC [1] (I just had to fix 1 place), I was convinced that the 
correct case is lowercase when reading asfext definition [2]
once again, I'm not an expert then could misinterpret the content, but I read 
http://projects.apache.org/ns/asfext#pmc";> as a 
definition of pmc field, in lowercase


since I was working on projects-new.a.o, I completely forgot to try to 
generate the current projects.a.o to check that the change didn't break 
anything: sorry, I'll try it tonight

one question: where is the cron log of the effective run?

Regards,

Hervé


[1] http://projects.apache.org/docs/pmc.html

[2] http://projects.apache.org/ns/asfext

Le lundi 4 mai 2015 01:39:45 sebb a écrit :
> XPath nodes are case-sensitive;  is not the same as
> .
> 
> The change from PMC to pmc has broken some of the reports - the PMC
> name is missing from most of the entries listed in
> http://projects.apache.org/indexes/pmc.html.
> 
> I don't know which case is correct, but there are currently RDF files
> in project repos which use PMC rather than pmc.
> These files are not easy to fix, as each project has to be asked to do them.
> 
> I can probably fix the scripts to check for both, but that is quite messy.
> 
> It would be better to use the "correct" case setting throughout
> (whatever that is).
> It looks like the original xsl file only used PMC, however a fairly
> early revision started using pmc and continued using PMC.
> Perhaps there was always an issue with some of the reports?
> 
> Until the correct setting is established, there's no point asking
> projects to fix their RDF files.
> 
> I don't know if there is a formal description of the syntax anywhere.
> 
> On 14 April 2015 at 00:00, Hervé BOUTEMY  wrote:
> > ok, it seems I can update the source, then I did it
> > 
> > I suppose this will be published in the next site content generation...
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le dimanche 12 avril 2015 04:41:22 Hervé BOUTEMY a écrit :
> >> Hi,
> >> 
> >> I'm working on http://projects-new.apache.org/ , which makes me dig into
> >> ASF DOAP conventions
> >> 
> >> And I found something that I think is a bug: on
> >> http://projects.apache.org/docs/pmc.html , half of the page explains
> >> about
> >> asfext:PMC in uppercase, while the other half is about asfext:pmc in
> >> lowercase
> >> 
> >> AFAIK, everybody is using asfext:pmc, in lowercase
> >> 
> >> Can you confirm that it is in lowercase? Then fix the page, that is
> >> causing
> >> a little bit of confusion?
> >> 
> >> Thanks in advance,
> >> 
> >> Hervé

Re: DOAP format question

[sebb]

There are 7 projects currently that maintain their own PMC RDF files.
Alll of these use asfext:PMC (not pmc).

However it looks like all of the project DOAP files use asfext:pmc
rather than PMC.

So the path of least resistance is clearly to use lower-case.


On 4 May 2015 at 01:39, sebb  wrote:
> XPath nodes are case-sensitive;  is not the same as .
>
> The change from PMC to pmc has broken some of the reports - the PMC
> name is missing from most of the entries listed in
> http://projects.apache.org/indexes/pmc.html.
>
> I don't know which case is correct, but there are currently RDF files
> in project repos which use PMC rather than pmc.
> These files are not easy to fix, as each project has to be asked to do them.
>
> I can probably fix the scripts to check for both, but that is quite messy.
>
> It would be better to use the "correct" case setting throughout
> (whatever that is).
> It looks like the original xsl file only used PMC, however a fairly
> early revision started using pmc and continued using PMC.
> Perhaps there was always an issue with some of the reports?
>
> Until the correct setting is established, there's no point asking
> projects to fix their RDF files.
>
> I don't know if there is a formal description of the syntax anywhere.
>
>
> On 14 April 2015 at 00:00, Hervé BOUTEMY  wrote:
>> ok, it seems I can update the source, then I did it
>>
>> I suppose this will be published in the next site content generation...
>>
>> Regards,
>>
>> Hervé
>>
>> Le dimanche 12 avril 2015 04:41:22 Hervé BOUTEMY a écrit :
>>> Hi,
>>>
>>> I'm working on http://projects-new.apache.org/ , which makes me dig into ASF
>>> DOAP conventions
>>>
>>> And I found something that I think is a bug: on
>>> http://projects.apache.org/docs/pmc.html , half of the page explains about
>>> asfext:PMC in uppercase, while the other half is about asfext:pmc in
>>> lowercase
>>>
>>> AFAIK, everybody is using asfext:pmc, in lowercase
>>>
>>> Can you confirm that it is in lowercase? Then fix the page, that is causing
>>> a little bit of confusion?
>>>
>>> Thanks in advance,
>>>
>>> Hervé
>>