Re: DOAP format question

[Hervé BOUTEMY]

I started generating /doap/{tlp-id}/pmc.rdf
Please tell me what to add in these files

I don't understand what to write into /doap/foundation/tlps.rdf

And for /doap/{tlp-id}/{project-id}.rdf, the content can't be generated: there 
is a lot of handwritten content we can't guess automatically
What we can do is copying projects hadcrafted content to the structured 
location: but even extracting the {project-id} is not easy

any idea?

Regards,

Hervé

Le mardi 12 mai 2015 18:23:12 Sergio Fernández a écrit :
> Hi,
> 
> On Tue, May 12, 2015 at 8:47 AM, Hervé BOUTEMY 
> 
> wrote:
> > I think we could generate an authoritative DOAP url for TLPs from
> > committee-
> > info.txt
> > then give instructions to projects to update their software DOAP files to
> > point
> > to these reference TLPs DOAP files
> 
> Exactly. I think a conclusion we could arrive with the years using DOAP
> files in ASF is simple: handcrafted files are
> 
> So I think the goal for projects-new.apache.org would be to automatically
> generate the DOAP files, including: TLPs (PMCs), projects and releases. We
> have that data somewhere (LDAP?), I'm pretty sure, we just need to get it
> and process it.
> 
> > I can generate tonight http://projects-new.apache.org/doap/tlp/ as a POC
> > for
> > 
> > https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/
> > data_files replacement
> 
> OK, bootstrap it, and then I'll jump it to do the proper RDF coding there.
> 
> I'll propose to publish at least:
> 
>   1) /doap/foundation/tlps.rdf
>   2) /doap/{tlp-id}/pmc.rdf
>   3) /doap/{tlp-id}/{project-id}.rdf
> 
> 1 will provide the basic information, linking to 2 containing the pmc
> information, as we already do in json. Then 3 would also link to 2, where
> in most of the cases {tlp-id} and {project-id} will be the same, but we do
> support subprojects (e.g., lucene) and components (e.g., commons).
> 
> One we have that infrastructure in place, we can tell all TLPs to directly
> link to those files, avoiding the manual duplication of that data.
> 
> I think with that we are coming closer to a satisfactory solution ;-)

Re: DOAP format question

[Betty James]

Please delete me from this thread if you can.
Betty B. James

On Tue, May 12, 2015 at 12:23 PM, Sergio Fernández 
wrote:

> Hi,
>
> On Tue, May 12, 2015 at 8:47 AM, Hervé BOUTEMY 
> wrote:
> >
> > I think we could generate an authoritative DOAP url for TLPs from
> > committee-
> > info.txt
> > then give instructions to projects to update their software DOAP files to
> > point
> > to these reference TLPs DOAP files
> >
>
> Exactly. I think a conclusion we could arrive with the years using DOAP
> files in ASF is simple: handcrafted files are
>
> So I think the goal for projects-new.apache.org would be to automatically
> generate the DOAP files, including: TLPs (PMCs), projects and releases. We
> have that data somewhere (LDAP?), I'm pretty sure, we just need to get it
> and process it.
>
>
> > I can generate tonight http://projects-new.apache.org/doap/tlp/ as a POC
> > for
> >
> >
> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files
> > replacement
> >
>
> OK, bootstrap it, and then I'll jump it to do the proper RDF coding there.
>
> I'll propose to publish at least:
>
>   1) /doap/foundation/tlps.rdf
>   2) /doap/{tlp-id}/pmc.rdf
>   3) /doap/{tlp-id}/{project-id}.rdf
>
> 1 will provide the basic information, linking to 2 containing the pmc
> information, as we already do in json. Then 3 would also link to 2, where
> in most of the cases {tlp-id} and {project-id} will be the same, but we do
> support subprojects (e.g., lucene) and components (e.g., commons).
>
> One we have that infrastructure in place, we can tell all TLPs to directly
> link to those files, avoiding the manual duplication of that data.
>
> I think with that we are coming closer to a satisfactory solution ;-)
>
> --
> 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]

Hi,

On Tue, May 12, 2015 at 8:47 AM, Hervé BOUTEMY 
wrote:
>
> I think we could generate an authoritative DOAP url for TLPs from
> committee-
> info.txt
> then give instructions to projects to update their software DOAP files to
> point
> to these reference TLPs DOAP files
>

Exactly. I think a conclusion we could arrive with the years using DOAP
files in ASF is simple: handcrafted files are

So I think the goal for projects-new.apache.org would be to automatically
generate the DOAP files, including: TLPs (PMCs), projects and releases. We
have that data somewhere (LDAP?), I'm pretty sure, we just need to get it
and process it.


> I can generate tonight http://projects-new.apache.org/doap/tlp/ as a POC
> for
>
> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files
> replacement
>

OK, bootstrap it, and then I'll jump it to do the proper RDF coding there.

I'll propose to publish at least:

  1) /doap/foundation/tlps.rdf
  2) /doap/{tlp-id}/pmc.rdf
  3) /doap/{tlp-id}/{project-id}.rdf

1 will provide the basic information, linking to 2 containing the pmc
information, as we already do in json. Then 3 would also link to 2, where
in most of the cases {tlp-id} and {project-id} will be the same, but we do
support subprojects (e.g., lucene) and components (e.g., commons).

One we have that infrastructure in place, we can tell all TLPs to directly
link to those files, avoiding the manual duplication of that data.

I think with that we are coming closer to a satisfactory solution ;-)

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

Re: DOAP format question

[Hervé BOUTEMY]

Le lundi 11 mai 2015 08:46:41 Sergio Fernández a écrit :
> Hi sebb,
> 
> On Tue, May 5, 2015 at 7:08 PM, sebb  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.
I fear that's true :/
let's analyze what is wrong and fix it :)

> 
> Taking commons-lang as example, they currently have:
> 
>   http://commons.apache.org/lang/";>
> http://commons.apache.org/"/>
>   
> 
> which does not really link (in RDF) to the file
> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/da
> ta_files/commons.rdf
> 
> 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.
> 
> 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.
while working on it, I think I found one root cause: we're not clear about 
TLPs (with PMCs) vs software (often called "projects" too, but that have 
releases)

it seems 
https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files
 is about TLPs/PMCs
and "classical" DOAP files written by people are about softwares that are done 
by TLPs/PMCs

We have a TLPs/PMCs authoritative source of information: that is committee-
info.txt
I used it as main source of data for
https://projects-new.apache.org/json/foundation/tlps.json
The only informations in tlps.json that do not come from committee-info.txt 
are:
- committers list (committee-info.txt only lists PMC members, LDAP gives 
committers)
- description of the TLPs: I'm still looking which could be the authoritative 
information source

for more details, the parsing code is here:
http://svn.apache.org/viewvc/comdev/projects.apache.org/scripts/import/parsecommittees.py?view=markup

I think we could generate an authoritative DOAP url for TLPs from committee-
info.txt
then give instructions to projects to update their software DOAP files to point 
to these reference TLPs DOAP files

this would:
- fix issues regarding standard DOAP/RDF semantics
- be easy to explain

I can generate tonight http://projects-new.apache.org/doap/tlp/ as a POC for 
https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files
 replacement

notice: from TLP and PMC, I prefer to talk about TLP, since the TLP has a PMC 
+ a homepage, committers, and other attributes

WDYT?

Regards,

Hervé

> 
> Let me try to find some time to put some of these things in order to have a
> better overview...

Re: DOAP format question

[sebb]

On 11 May 2015 at 13:21, Sergio Fernández  wrote:
> Hi,
>
> On Mon, May 11, 2015 at 1:13 PM, sebb  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

Re: DOAP format question

[Sergio Fernández]

Hi,

On Mon, May 11, 2015 at 1:13 PM, sebb  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

Re: DOAP format question

[sebb]

On 11 May 2015 at 07:46, Sergio Fernández  wrote:
> Hi sebb,
>
> On Tue, May 5, 2015 at 7:08 PM, sebb  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:
>
>   http://commons.apache.org/lang/";>
> http://commons.apache.org/"/>
>   
>
> 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
"commons"
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
files.
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.fernan...@redlink.co
> w: http://redlink.co

Re: DOAP format question

[Sergio Fernández]

Hi sebb,

On Tue, May 5, 2015 at 7:08 PM, sebb  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:

  http://commons.apache.org/lang/";>
http://commons.apache.org/"/>
  

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

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.

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.fernan...@redlink.co
w: http://redlink.co

Re: DOAP format question

[sebb]

On 5 May 2015 at 16:57, Sergio Fernández  wrote:
> Hi,
>
> On Tue, May 5, 2015 at 4:39 PM, sebb  wrote:
>>
>> > One question, sebb, how the site development is organize? Do you use
>> jira or
>> > something as any other project does? Just to do the things properly
>> > according your guidelines.
>>
>> It's not a regular project.
>> I don't know who "owns" the code - possibly Infra or maybe ComDev.
>>
>> I have just been making the occasional fix as I notice problems.
>>
>> The site-dev and dev@community mailing list are probably the place to
>> discuss changes.
>
>
> OK, then I stay in this thread for discussion about this.
>
> I didn't have much time today, but what I already did was implementing the
> basics of how the DOAP processing could look like. For the moment is at
> https://github.com/wikier/asf-doap until I'll get something more
> functional, then I'll commit it to the asf repo.
>
> Basically what if currently does that simple code is to get all DOAP/PMC
> files and report some basics (size). You can run it by yourself executing:
>
> $ python doap.py
>
> 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.

The contents and locations of the various files are documented on the site.

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

> Because asfext:pmc is defined as a property in the
> namespace (as we discussed couple of days ago), so I missed the subject
> where it refers to (normally it should be used  asfext:pmc
> <...>). According that usage of the term, I guess they actually wanted to
> define a class.
>
> But please, let me evolve a bit more the code for giving you some basic
> tools, and then I can discuss further such aspects.
>
> 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]

Hi,

On Tue, May 5, 2015 at 4:39 PM, sebb  wrote:
>
> > One question, sebb, how the site development is organize? Do you use
> jira or
> > something as any other project does? Just to do the things properly
> > according your guidelines.
>
> It's not a regular project.
> I don't know who "owns" the code - possibly Infra or maybe ComDev.
>
> I have just been making the occasional fix as I notice problems.
>
> The site-dev and dev@community mailing list are probably the place to
> discuss changes.


OK, then I stay in this thread for discussion about this.

I didn't have much time today, but what I already did was implementing the
basics of how the DOAP processing could look like. For the moment is at
https://github.com/wikier/asf-doap until I'll get something more
functional, then I'll commit it to the asf repo.

Basically what if currently does that simple code is to get all DOAP/PMC
files and report some basics (size). You can run it by yourself executing:

$ python doap.py

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. Because asfext:pmc is defined as a property in the
namespace (as we discussed couple of days ago), so I missed the subject
where it refers to (normally it should be used  asfext:pmc
<...>). According that usage of the term, I guess they actually wanted to
define a class.

But please, let me evolve a bit more the code for giving you some basic
tools, and then I can discuss further such aspects.

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 5 May 2015 at 14:58, Sergio Fernández  wrote:
> On Tue, May 5, 2015 at 12:51 PM, sebb  wrote:
>>
>> Checking for such simple typos could be done with almost any scripting
>> language.
>>
>> The RDF files are listed in
>>
>>
>> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml
>> (DOAPs)
>> and
>>
>> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/pmc_list.xml
>> (PMC definitions)
>>
>> Most of the PMC definitions are stored locally, and have already been
>> fixed.
>
>
> OK, in the next day I'll provide a basic implementation (Python+RDFLib) that
> provides some kind of validation and reporting of pitfails. So later we can
> extend that add proper DOAP support to the projects-new.a.o.
>
> One question, sebb, how the site development is organize? Do you use jira or
> something as any other project does? Just to do the things properly
> according your guidelines.

It's not a regular project.
I don't know who "owns" the code - possibly Infra or maybe ComDev.

I have just been making the occasional fix as I notice problems.

The site-dev and dev@community mailing list are probably the place to
discuss changes.

> 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 Tue, May 5, 2015 at 12:51 PM, sebb  wrote:
>
> Checking for such simple typos could be done with almost any scripting
> language.
>
> The RDF files are listed in
>
>
> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml
> (DOAPs)
> and
>
> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/pmc_list.xml
> (PMC definitions)
>
> Most of the PMC definitions are stored locally, and have already been
> fixed.
>

OK, in the next day I'll provide a basic implementation (Python+RDFLib)
that provides some kind of validation and reporting of pitfails. So later
we can extend that add proper DOAP support to the projects-new.a.o.

One question, sebb, how the site development is organize? Do you use jira
or something as any other project does? Just to do the things properly
according your guidelines.

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 5 May 2015 at 07:06, Hervé BOUTEMY  wrote:
> 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

Ideally, yes, but as already noted that is not trivial.

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

It's possible to add warning checks to the cron job scripts, but this
will create a lot of noisy e-mails until projects have been notified
and fixed their files.
Experience shows that fixing DOAPs can take months for some PMCs.

One approach that might be worth trying is creating an additional
on-demand report that checks the list of RDFs for known issues.
Initially it could just check for asfext:PMC, but could be extended as
other issues are found or better syntax checking is available.

Checking for such simple typos could be done with almost any scripting language.

The RDF files are listed in

https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml
(DOAPs)
and
https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/pmc_list.xml
(PMC definitions)

Most of the PMC definitions are stored locally, and have already been fixed.

> Regards,
>
> Hervé
>
>>
>> > 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

[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

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

Re: DOAP format question

[sebb]

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]

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é