You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2015/03/28 14:13:48 UTC

[COMMONSRDF] GroupID for incubation releases

Hi guys,

there is a discussion in COMMONSRDF-2 [1] about the maven coordinates for
incubation releases of Commons RDF. I may have missed something, but my
last information was, that Commons RDF has not yet decided whether it
want's to join Apache Commons or go TLP in the end. So the situation looks
like the following to me:

As long as Commons RDF has not decided to join Apache Commons in the end,
Commons RDF should not use the Apache Commons groupid. So maven coordinates
should be:

<groupid>org.apache.commonsrdf</groupid>
<artifactid>commons-rdf</artifactid>

If Commons RDF has already decided not to go TLP and to join Apache Commons
after incubation, the coordinates should be (have i missed that decision?
Sorry!):

<groupid>org.apache.commons</groupid>
<artifactid>commons-rdf</artifactid>

Regards,
Benedikt

[1] https://issues.apache.org/jira/browse/COMMONSRDF-2

-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
On Thu, Apr 16, 2015 at 7:41 AM, Sergio Fernández <wi...@apache.org> wrote:

> Hi,
>
> On Wed, Apr 15, 2015 at 12:30 PM, Reto Gmür <re...@apache.org> wrote:
>
> > On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández <wi...@apache.org>
> > wrote:
> >
> > > On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell <an...@gmail.com>
> > > wrote:
> > > >
> > > > BlankNodes cannot be compared across different SPARQL queries. That
> is
> > > > a well known RDF issue, not just with SPARQL, and is not going to be
> > > > solved by anything except bulk execution of a single query to get all
> > > > of the BlankNodes back in a single query.
> > >
> > >
> > > I think that's something where we all can agree, isn't it?
> > >
> >
> > No, there is no need to get all of the blank-nodes (of the graph) back.
> > It's enough to get the context (aka minimum self contained graph, aka
> > symmetric concise bounded description), this is what impl.sparql in
> > clerezza commons RDF does. That's why if we have to assign a string
> > identifier to it this would have to be a strong digest of this context
> > graph and an indicator of the position of the node within it.
>
>
> I could understand that need, but i still think is a very concrete use
> case. Therefore I'd prefer to keep the api contracts as they were, keeping
> such concrete aspect up to each implementation.
>
> Is that something what we could agree on?
>

Not sure what the agreement would be.

The API are being redefined. For example apparently there has been a
"decision" somewhere (maybe on Github?) that BlankNode identity should no
longer be scoped but depend exclusively on their ID.

I've just presented two usecases where a BlankNode ID is problematic, as
the BlankNode ID is not part of the RDF spec I suggest not to have it in
the API, but as there seem to exist strong opinion to keep the BlankNode ID
I've created COMMONSRDF-13 inviting to show some concrete code that
benefits from having such an ID exposed, of course this would also allow me
to show if this usecases can be rewritten without the exposed IDs.

Cheers,
Reto



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

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
On Thu, Apr 16, 2015 at 7:41 AM, Sergio Fernández <wi...@apache.org> wrote:

> Hi,
>
> On Wed, Apr 15, 2015 at 12:30 PM, Reto Gmür <re...@apache.org> wrote:
>
> > On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández <wi...@apache.org>
> > wrote:
> >
> > > On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell <an...@gmail.com>
> > > wrote:
> > > >
> > > > BlankNodes cannot be compared across different SPARQL queries. That
> is
> > > > a well known RDF issue, not just with SPARQL, and is not going to be
> > > > solved by anything except bulk execution of a single query to get all
> > > > of the BlankNodes back in a single query.
> > >
> > >
> > > I think that's something where we all can agree, isn't it?
> > >
> >
> > No, there is no need to get all of the blank-nodes (of the graph) back.
> > It's enough to get the context (aka minimum self contained graph, aka
> > symmetric concise bounded description), this is what impl.sparql in
> > clerezza commons RDF does. That's why if we have to assign a string
> > identifier to it this would have to be a strong digest of this context
> > graph and an indicator of the position of the node within it.
>
>
> I could understand that need, but i still think is a very concrete use
> case. Therefore I'd prefer to keep the api contracts as they were, keeping
> such concrete aspect up to each implementation.
>
> Is that something what we could agree on?
>

Not sure what the agreement would be.

The API are being redefined. For example apparently there has been a
"decision" somewhere (maybe on Github?) that BlankNode identity should no
longer be scoped but depend exclusively on their ID.

I've just presented two usecases where a BlankNode ID is problematic, as
the BlankNode ID is not part of the RDF spec I suggest not to have it in
the API, but as there seem to exist strong opinion to keep the BlankNode ID
I've created COMMONSRDF-13 inviting to show some concrete code that
benefits from having such an ID exposed, of course this would also allow me
to show if this usecases can be rewritten without the exposed IDs.

Cheers,
Reto



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

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Sergio Fernández <wi...@apache.org>.
Hi,

On Wed, Apr 15, 2015 at 12:30 PM, Reto Gmür <re...@apache.org> wrote:

> On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández <wi...@apache.org>
> wrote:
>
> > On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell <an...@gmail.com>
> > wrote:
> > >
> > > BlankNodes cannot be compared across different SPARQL queries. That is
> > > a well known RDF issue, not just with SPARQL, and is not going to be
> > > solved by anything except bulk execution of a single query to get all
> > > of the BlankNodes back in a single query.
> >
> >
> > I think that's something where we all can agree, isn't it?
> >
>
> No, there is no need to get all of the blank-nodes (of the graph) back.
> It's enough to get the context (aka minimum self contained graph, aka
> symmetric concise bounded description), this is what impl.sparql in
> clerezza commons RDF does. That's why if we have to assign a string
> identifier to it this would have to be a strong digest of this context
> graph and an indicator of the position of the node within it.


I could understand that need, but i still think is a very concrete use
case. Therefore I'd prefer to keep the api contracts as they were, keeping
such concrete aspect up to each implementation.

Is that something what we could agree on?

Thanks.

Cheers,

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

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Sergio Fernández <wi...@apache.org>.
Hi,

On Wed, Apr 15, 2015 at 12:30 PM, Reto Gmür <re...@apache.org> wrote:

> On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández <wi...@apache.org>
> wrote:
>
> > On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell <an...@gmail.com>
> > wrote:
> > >
> > > BlankNodes cannot be compared across different SPARQL queries. That is
> > > a well known RDF issue, not just with SPARQL, and is not going to be
> > > solved by anything except bulk execution of a single query to get all
> > > of the BlankNodes back in a single query.
> >
> >
> > I think that's something where we all can agree, isn't it?
> >
>
> No, there is no need to get all of the blank-nodes (of the graph) back.
> It's enough to get the context (aka minimum self contained graph, aka
> symmetric concise bounded description), this is what impl.sparql in
> clerezza commons RDF does. That's why if we have to assign a string
> identifier to it this would have to be a strong digest of this context
> graph and an indicator of the position of the node within it.


I could understand that need, but i still think is a very concrete use
case. Therefore I'd prefer to keep the api contracts as they were, keeping
such concrete aspect up to each implementation.

Is that something what we could agree on?

Thanks.

Cheers,

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

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández <wi...@apache.org> wrote:

> On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell <an...@gmail.com>
> wrote:
> >
> > BlankNodes cannot be compared across different SPARQL queries. That is
> > a well known RDF issue, not just with SPARQL, and is not going to be
> > solved by anything except bulk execution of a single query to get all
> > of the BlankNodes back in a single query.
>
>
> I think that's something where we all can agree, isn't it?
>

No, there is no need to get all of the blank-nodes (of the graph) back.
It's enough to get the context (aka minimum self contained graph, aka
symmetric concise bounded description), this is what impl.sparql in
clerezza commons RDF does. That's why if we have to assign a string
identifier to it this would have to be a strong digest of this context
graph and an indicator of the position of the node within it.

Cheers,
Reto

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández <wi...@apache.org> wrote:

> On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell <an...@gmail.com>
> wrote:
> >
> > BlankNodes cannot be compared across different SPARQL queries. That is
> > a well known RDF issue, not just with SPARQL, and is not going to be
> > solved by anything except bulk execution of a single query to get all
> > of the BlankNodes back in a single query.
>
>
> I think that's something where we all can agree, isn't it?
>

No, there is no need to get all of the blank-nodes (of the graph) back.
It's enough to get the context (aka minimum self contained graph, aka
symmetric concise bounded description), this is what impl.sparql in
clerezza commons RDF does. That's why if we have to assign a string
identifier to it this would have to be a strong digest of this context
graph and an indicator of the position of the node within it.

Cheers,
Reto

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Sergio Fernández <wi...@apache.org>.
On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell <an...@gmail.com>
wrote:
>
> BlankNodes cannot be compared across different SPARQL queries. That is
> a well known RDF issue, not just with SPARQL, and is not going to be
> solved by anything except bulk execution of a single query to get all
> of the BlankNodes back in a single query.


I think that's something where we all can agree, isn't it?

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

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
Hi Peter,

I wrote some code to better answer the second part of your email.


> > Besides the SPARQL usecase, here's a simple usecase for wrapping data as
> > RDF:
> >
> > interface Person {
> >    String getFirstName();
> >    String getLastName();
> >    String getDiary()
> > }
> >
> > interface DataBase() {
> >   Interator<Person> list();
> >   Interator<Person> filterByLastName(String);
> >   Interator<Person> filterByFirstName(String);
> > }
> >
> > No the task is to expose this dynamically as RDF (i.e. without
> duplicating
> > the data).
> >
> > Wrapping this with clerezza one would wrap the Person instance in a
> > blanknode, the identity of the BlankNode would depend on the identity of
> > the Person instance. Doing the same with the incubating commons rdf
> > proposal would require keeping a Bidirectional Weak Hashmap of from
> > Blanknode identifiers to Person objects. I don't think many programmers
> > would like to do the latter, so I don't think it is currently a suitable
> > API for exposing arbitrary data using the RDF datamodel.
>
> If there is no single or aggregate primary key for a person, then it
> will not work reliably with any database,
> RDF/Graph/Document/NoSQL/Relational/etc. It works internally in
> Clerezza, in-memory, with the added BlankNode object wrapper, and
> could be mapped using BlankNode.internalIdentifier. It isn't helpful
> to use arguments about not liking a method to imply it is impossible.
>

I did not say that it is impossible, I just say that it takes additional
code and uses additional memory (memory usage can be minimized by using a
bidirectional weak hashmap).

Here I've implemented the simple usecase using Clerezza:
https://github.com/retog/rdfwrapper-example. The actual wrapper class is
here:
https://github.com/retog/rdfwrapper-example/blob/master/clerezza-based-wrapper/src/main/java/org/example/clerezza/based/wrapper/PersonDataBaseGraph.java
.

I think an API should be evaluated by the elegance and efficiency it allows
to implement different usecases. Even if you think that the example is
badly chosen and in reality persons would always come with identifiers I
invite you to implement the same functionality with your API proposal,
after all we should be able to wrap even a crappy API that does not expose
the primary key of the underlying database. Note that the Clerezza Commons
RDF based implementation works with constant memory even if the backend
exposes billions of persons.

I think comparing code and it's properties it's the best way to compare
APIs, so I hope you - or someone else - will accept the invitation.

Cheers,
Reto

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
Hi Peter,

I wrote some code to better answer the second part of your email.


> > Besides the SPARQL usecase, here's a simple usecase for wrapping data as
> > RDF:
> >
> > interface Person {
> >    String getFirstName();
> >    String getLastName();
> >    String getDiary()
> > }
> >
> > interface DataBase() {
> >   Interator<Person> list();
> >   Interator<Person> filterByLastName(String);
> >   Interator<Person> filterByFirstName(String);
> > }
> >
> > No the task is to expose this dynamically as RDF (i.e. without
> duplicating
> > the data).
> >
> > Wrapping this with clerezza one would wrap the Person instance in a
> > blanknode, the identity of the BlankNode would depend on the identity of
> > the Person instance. Doing the same with the incubating commons rdf
> > proposal would require keeping a Bidirectional Weak Hashmap of from
> > Blanknode identifiers to Person objects. I don't think many programmers
> > would like to do the latter, so I don't think it is currently a suitable
> > API for exposing arbitrary data using the RDF datamodel.
>
> If there is no single or aggregate primary key for a person, then it
> will not work reliably with any database,
> RDF/Graph/Document/NoSQL/Relational/etc. It works internally in
> Clerezza, in-memory, with the added BlankNode object wrapper, and
> could be mapped using BlankNode.internalIdentifier. It isn't helpful
> to use arguments about not liking a method to imply it is impossible.
>

I did not say that it is impossible, I just say that it takes additional
code and uses additional memory (memory usage can be minimized by using a
bidirectional weak hashmap).

Here I've implemented the simple usecase using Clerezza:
https://github.com/retog/rdfwrapper-example. The actual wrapper class is
here:
https://github.com/retog/rdfwrapper-example/blob/master/clerezza-based-wrapper/src/main/java/org/example/clerezza/based/wrapper/PersonDataBaseGraph.java
.

I think an API should be evaluated by the elegance and efficiency it allows
to implement different usecases. Even if you think that the example is
badly chosen and in reality persons would always come with identifiers I
invite you to implement the same functionality with your API proposal,
after all we should be able to wrap even a crappy API that does not expose
the primary key of the underlying database. Note that the Clerezza Commons
RDF based implementation works with constant memory even if the backend
exposes billions of persons.

I think comparing code and it's properties it's the best way to compare
APIs, so I hope you - or someone else - will accept the invitation.

Cheers,
Reto

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Sergio Fernández <wi...@apache.org>.
On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell <an...@gmail.com>
wrote:
>
> BlankNodes cannot be compared across different SPARQL queries. That is
> a well known RDF issue, not just with SPARQL, and is not going to be
> solved by anything except bulk execution of a single query to get all
> of the BlankNodes back in a single query.


I think that's something where we all can agree, isn't it?

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

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Peter Ansell <an...@gmail.com>.
On 14 April 2015 at 01:16, Reto Gmür <re...@apache.org> wrote:
> On Sat, Apr 11, 2015 at 12:39 PM, Peter Ansell <an...@gmail.com>
> wrote:
>
>> On 11 April 2015 at 22:11, Reto Gmür <re...@apache.org> wrote:
>> > On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter <br...@apache.org>
>> wrote:
>> >
>> >> Hello Reto,
>> >>
>> >> 2015-03-30 14:45 GMT+02:00 Reto Gmür <re...@apache.org>:
>> >>
>> >> > Hi all,
>> >> >
>> >> > The clerezza commons RDF proposal that was in the sandbox and is now
>> in
>> >> the
>> >> > clerezza-rdf-core repository has been changed to use
>> >> > org.apache.clerezza.commons-rdf.
>> >> >
>> >> > As you know if all goes well clerezza will be based in the result of
>> the
>> >> > incubating project. If however this project should unfortunately not
>> lead
>> >> > to something generic enough to be used for interfacing arbitrary data
>> as
>> >> > RDF and thus be usable for clerezza, then clerezza might reactivate
>> its
>> >> > commons-rdf proposal. It would then be up to commons to decide which
>> >> > proposal to adopt and under which name.
>> >> >
>> >>
>> >> We (the Apache Commons community) have already stated, that we don't
>> have
>> >> the necessary knowledge about RDF to make such a decision. I would
>> prefer
>> >> more people from clerezza joining this ML and build consensus with the
>> >> incubating commons rdf community about how an implementation of the RDF
>> >> specification should look like.
>> >>
>> >
>> > It might be hard to reach an acceptable solution if the result of one
>> year
>> > on Github are taken as unmodifiable except when there is 100% agreement
>> on
>> > a change.
>>
>> You were privy to all of the public discussions on GitHub, and many of
>> the private discussions just before setting up the project publicly.
>> Please do not imply that this was your first opportunity to bring up
>> these issues, or that we had not responded at all to the issues you did
>> bring up in the past.
>>
>
> The first discussions we had were at the end of 2012 on public apache
> mailing lists.
>
>
>
>>
>> Apart from the structural constraints of having an entire interface
>> driven API, and there being no clear reason why the interface names
>> themselves should be changed to suit you,
>
>
> I've changed clerezza to mach the names in rdf-commons classes. I would
> have preferred an decision on a casing conventions rather than just a
> statement that these types are named like that and will not change.
>
>
>> do you have other issues
>> where getting ~100 percent agreement has failed and you would like
>> some further discussion.
>>
>
> I've created COMMONSRDF-13 to address one of the main issues.
>
>
>>
>> > Even without having the commons community diving deep into RDF it might
>> > become clear that one API is better suited for triple stores and their
>> > requirement while the other is more suitable to exposing arbitrary data
>> > source using the RDF model. So if the result is not something that can be
>> > used in all usecases having two commons project relating to RDF but with
>> an
>> > distinct goal might also be an option.
>>
>> If you could articulate why the current interface based method makes
>> it unsuitable for your use cases it would definitely help. In
>> particular, some examples of where Clerezza could map a data source to
>> RDF somewhow, but it would be impossible with commons-rdf-api, then we
>> can start to discuss it further. Right now you have only implied that
>> the difficulty exists without articulating it.
>>
>
> I've written code that exposes a SPARQL endpoint using the clerezza version
> of RDF Commons, I've argued that it would be quite hard to do the same with
> the incubating Commons RDF proposal [1]. The reply on the list was that we
> will worry about that later, but in my opinion this shows a fundamental
> limitation of the current approach.

BlankNodes cannot be compared across different SPARQL queries. That is
a well known RDF issue, not just with SPARQL, and is not going to be
solved by anything except bulk execution of a single query to get all
of the BlankNodes back in a single query.

> Besides the SPARQL usecase, here's a simple usecase for wrapping data as
> RDF:
>
> interface Person {
>    String getFirstName();
>    String getLastName();
>    String getDiary()
> }
>
> interface DataBase() {
>   Interator<Person> list();
>   Interator<Person> filterByLastName(String);
>   Interator<Person> filterByFirstName(String);
> }
>
> No the task is to expose this dynamically as RDF (i.e. without duplicating
> the data).
>
> Wrapping this with clerezza one would wrap the Person instance in a
> blanknode, the identity of the BlankNode would depend on the identity of
> the Person instance. Doing the same with the incubating commons rdf
> proposal would require keeping a Bidirectional Weak Hashmap of from
> Blanknode identifiers to Person objects. I don't think many programmers
> would like to do the latter, so I don't think it is currently a suitable
> API for exposing arbitrary data using the RDF datamodel.

If there is no single or aggregate primary key for a person, then it
will not work reliably with any database,
RDF/Graph/Document/NoSQL/Relational/etc. It works internally in
Clerezza, in-memory, with the added BlankNode object wrapper, and
could be mapped using BlankNode.internalIdentifier. It isn't helpful
to use arguments about not liking a method to imply it is impossible.

Cheers,

Peter

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Peter Ansell <an...@gmail.com>.
On 14 April 2015 at 01:16, Reto Gmür <re...@apache.org> wrote:
> On Sat, Apr 11, 2015 at 12:39 PM, Peter Ansell <an...@gmail.com>
> wrote:
>
>> On 11 April 2015 at 22:11, Reto Gmür <re...@apache.org> wrote:
>> > On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter <br...@apache.org>
>> wrote:
>> >
>> >> Hello Reto,
>> >>
>> >> 2015-03-30 14:45 GMT+02:00 Reto Gmür <re...@apache.org>:
>> >>
>> >> > Hi all,
>> >> >
>> >> > The clerezza commons RDF proposal that was in the sandbox and is now
>> in
>> >> the
>> >> > clerezza-rdf-core repository has been changed to use
>> >> > org.apache.clerezza.commons-rdf.
>> >> >
>> >> > As you know if all goes well clerezza will be based in the result of
>> the
>> >> > incubating project. If however this project should unfortunately not
>> lead
>> >> > to something generic enough to be used for interfacing arbitrary data
>> as
>> >> > RDF and thus be usable for clerezza, then clerezza might reactivate
>> its
>> >> > commons-rdf proposal. It would then be up to commons to decide which
>> >> > proposal to adopt and under which name.
>> >> >
>> >>
>> >> We (the Apache Commons community) have already stated, that we don't
>> have
>> >> the necessary knowledge about RDF to make such a decision. I would
>> prefer
>> >> more people from clerezza joining this ML and build consensus with the
>> >> incubating commons rdf community about how an implementation of the RDF
>> >> specification should look like.
>> >>
>> >
>> > It might be hard to reach an acceptable solution if the result of one
>> year
>> > on Github are taken as unmodifiable except when there is 100% agreement
>> on
>> > a change.
>>
>> You were privy to all of the public discussions on GitHub, and many of
>> the private discussions just before setting up the project publicly.
>> Please do not imply that this was your first opportunity to bring up
>> these issues, or that we had not responded at all to the issues you did
>> bring up in the past.
>>
>
> The first discussions we had were at the end of 2012 on public apache
> mailing lists.
>
>
>
>>
>> Apart from the structural constraints of having an entire interface
>> driven API, and there being no clear reason why the interface names
>> themselves should be changed to suit you,
>
>
> I've changed clerezza to mach the names in rdf-commons classes. I would
> have preferred an decision on a casing conventions rather than just a
> statement that these types are named like that and will not change.
>
>
>> do you have other issues
>> where getting ~100 percent agreement has failed and you would like
>> some further discussion.
>>
>
> I've created COMMONSRDF-13 to address one of the main issues.
>
>
>>
>> > Even without having the commons community diving deep into RDF it might
>> > become clear that one API is better suited for triple stores and their
>> > requirement while the other is more suitable to exposing arbitrary data
>> > source using the RDF model. So if the result is not something that can be
>> > used in all usecases having two commons project relating to RDF but with
>> an
>> > distinct goal might also be an option.
>>
>> If you could articulate why the current interface based method makes
>> it unsuitable for your use cases it would definitely help. In
>> particular, some examples of where Clerezza could map a data source to
>> RDF somewhow, but it would be impossible with commons-rdf-api, then we
>> can start to discuss it further. Right now you have only implied that
>> the difficulty exists without articulating it.
>>
>
> I've written code that exposes a SPARQL endpoint using the clerezza version
> of RDF Commons, I've argued that it would be quite hard to do the same with
> the incubating Commons RDF proposal [1]. The reply on the list was that we
> will worry about that later, but in my opinion this shows a fundamental
> limitation of the current approach.

BlankNodes cannot be compared across different SPARQL queries. That is
a well known RDF issue, not just with SPARQL, and is not going to be
solved by anything except bulk execution of a single query to get all
of the BlankNodes back in a single query.

> Besides the SPARQL usecase, here's a simple usecase for wrapping data as
> RDF:
>
> interface Person {
>    String getFirstName();
>    String getLastName();
>    String getDiary()
> }
>
> interface DataBase() {
>   Interator<Person> list();
>   Interator<Person> filterByLastName(String);
>   Interator<Person> filterByFirstName(String);
> }
>
> No the task is to expose this dynamically as RDF (i.e. without duplicating
> the data).
>
> Wrapping this with clerezza one would wrap the Person instance in a
> blanknode, the identity of the BlankNode would depend on the identity of
> the Person instance. Doing the same with the incubating commons rdf
> proposal would require keeping a Bidirectional Weak Hashmap of from
> Blanknode identifiers to Person objects. I don't think many programmers
> would like to do the latter, so I don't think it is currently a suitable
> API for exposing arbitrary data using the RDF datamodel.

If there is no single or aggregate primary key for a person, then it
will not work reliably with any database,
RDF/Graph/Document/NoSQL/Relational/etc. It works internally in
Clerezza, in-memory, with the added BlankNode object wrapper, and
could be mapped using BlankNode.internalIdentifier. It isn't helpful
to use arguments about not liking a method to imply it is impossible.

Cheers,

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
On Sat, Apr 11, 2015 at 12:39 PM, Peter Ansell <an...@gmail.com>
wrote:

> On 11 April 2015 at 22:11, Reto Gmür <re...@apache.org> wrote:
> > On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter <br...@apache.org>
> wrote:
> >
> >> Hello Reto,
> >>
> >> 2015-03-30 14:45 GMT+02:00 Reto Gmür <re...@apache.org>:
> >>
> >> > Hi all,
> >> >
> >> > The clerezza commons RDF proposal that was in the sandbox and is now
> in
> >> the
> >> > clerezza-rdf-core repository has been changed to use
> >> > org.apache.clerezza.commons-rdf.
> >> >
> >> > As you know if all goes well clerezza will be based in the result of
> the
> >> > incubating project. If however this project should unfortunately not
> lead
> >> > to something generic enough to be used for interfacing arbitrary data
> as
> >> > RDF and thus be usable for clerezza, then clerezza might reactivate
> its
> >> > commons-rdf proposal. It would then be up to commons to decide which
> >> > proposal to adopt and under which name.
> >> >
> >>
> >> We (the Apache Commons community) have already stated, that we don't
> have
> >> the necessary knowledge about RDF to make such a decision. I would
> prefer
> >> more people from clerezza joining this ML and build consensus with the
> >> incubating commons rdf community about how an implementation of the RDF
> >> specification should look like.
> >>
> >
> > It might be hard to reach an acceptable solution if the result of one
> year
> > on Github are taken as unmodifiable except when there is 100% agreement
> on
> > a change.
>
> You were privy to all of the public discussions on GitHub, and many of
> the private discussions just before setting up the project publicly.
> Please do not imply that this was your first opportunity to bring up
> these issues, or that we had not responded at all to the issues you did
> bring up in the past.
>

The first discussions we had were at the end of 2012 on public apache
mailing lists.



>
> Apart from the structural constraints of having an entire interface
> driven API, and there being no clear reason why the interface names
> themselves should be changed to suit you,


I've changed clerezza to mach the names in rdf-commons classes. I would
have preferred an decision on a casing conventions rather than just a
statement that these types are named like that and will not change.


> do you have other issues
> where getting ~100 percent agreement has failed and you would like
> some further discussion.
>

I've created COMMONSRDF-13 to address one of the main issues.


>
> > Even without having the commons community diving deep into RDF it might
> > become clear that one API is better suited for triple stores and their
> > requirement while the other is more suitable to exposing arbitrary data
> > source using the RDF model. So if the result is not something that can be
> > used in all usecases having two commons project relating to RDF but with
> an
> > distinct goal might also be an option.
>
> If you could articulate why the current interface based method makes
> it unsuitable for your use cases it would definitely help. In
> particular, some examples of where Clerezza could map a data source to
> RDF somewhow, but it would be impossible with commons-rdf-api, then we
> can start to discuss it further. Right now you have only implied that
> the difficulty exists without articulating it.
>

I've written code that exposes a SPARQL endpoint using the clerezza version
of RDF Commons, I've argued that it would be quite hard to do the same with
the incubating Commons RDF proposal [1]. The reply on the list was that we
will worry about that later, but in my opinion this shows a fundamental
limitation of the current approach.

Besides the SPARQL usecase, here's a simple usecase for wrapping data as
RDF:

interface Person {
   String getFirstName();
   String getLastName();
   String getDiary()
}

interface DataBase() {
  Interator<Person> list();
  Interator<Person> filterByLastName(String);
  Interator<Person> filterByFirstName(String);
}

No the task is to expose this dynamically as RDF (i.e. without duplicating
the data).

Wrapping this with clerezza one would wrap the Person instance in a
blanknode, the identity of the BlankNode would depend on the identity of
the Person instance. Doing the same with the incubating commons rdf
proposal would require keeping a Bidirectional Weak Hashmap of from
Blanknode identifiers to Person objects. I don't think many programmers
would like to do the latter, so I don't think it is currently a suitable
API for exposing arbitrary data using the RDF datamodel.

Cheers,
Reto

1.
http://mail-archives.apache.org/mod_mbox/commonsrdf-dev/201503.mbox/%3CCALvhUEXSSwO-Udj6ngdedVQuPC6n=+983UbnkYoBs2psY5kURg@mail.gmail.com%3E

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
On Sat, Apr 11, 2015 at 12:39 PM, Peter Ansell <an...@gmail.com>
wrote:

> On 11 April 2015 at 22:11, Reto Gmür <re...@apache.org> wrote:
> > On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter <br...@apache.org>
> wrote:
> >
> >> Hello Reto,
> >>
> >> 2015-03-30 14:45 GMT+02:00 Reto Gmür <re...@apache.org>:
> >>
> >> > Hi all,
> >> >
> >> > The clerezza commons RDF proposal that was in the sandbox and is now
> in
> >> the
> >> > clerezza-rdf-core repository has been changed to use
> >> > org.apache.clerezza.commons-rdf.
> >> >
> >> > As you know if all goes well clerezza will be based in the result of
> the
> >> > incubating project. If however this project should unfortunately not
> lead
> >> > to something generic enough to be used for interfacing arbitrary data
> as
> >> > RDF and thus be usable for clerezza, then clerezza might reactivate
> its
> >> > commons-rdf proposal. It would then be up to commons to decide which
> >> > proposal to adopt and under which name.
> >> >
> >>
> >> We (the Apache Commons community) have already stated, that we don't
> have
> >> the necessary knowledge about RDF to make such a decision. I would
> prefer
> >> more people from clerezza joining this ML and build consensus with the
> >> incubating commons rdf community about how an implementation of the RDF
> >> specification should look like.
> >>
> >
> > It might be hard to reach an acceptable solution if the result of one
> year
> > on Github are taken as unmodifiable except when there is 100% agreement
> on
> > a change.
>
> You were privy to all of the public discussions on GitHub, and many of
> the private discussions just before setting up the project publicly.
> Please do not imply that this was your first opportunity to bring up
> these issues, or that we had not responded at all to the issues you did
> bring up in the past.
>

The first discussions we had were at the end of 2012 on public apache
mailing lists.



>
> Apart from the structural constraints of having an entire interface
> driven API, and there being no clear reason why the interface names
> themselves should be changed to suit you,


I've changed clerezza to mach the names in rdf-commons classes. I would
have preferred an decision on a casing conventions rather than just a
statement that these types are named like that and will not change.


> do you have other issues
> where getting ~100 percent agreement has failed and you would like
> some further discussion.
>

I've created COMMONSRDF-13 to address one of the main issues.


>
> > Even without having the commons community diving deep into RDF it might
> > become clear that one API is better suited for triple stores and their
> > requirement while the other is more suitable to exposing arbitrary data
> > source using the RDF model. So if the result is not something that can be
> > used in all usecases having two commons project relating to RDF but with
> an
> > distinct goal might also be an option.
>
> If you could articulate why the current interface based method makes
> it unsuitable for your use cases it would definitely help. In
> particular, some examples of where Clerezza could map a data source to
> RDF somewhow, but it would be impossible with commons-rdf-api, then we
> can start to discuss it further. Right now you have only implied that
> the difficulty exists without articulating it.
>

I've written code that exposes a SPARQL endpoint using the clerezza version
of RDF Commons, I've argued that it would be quite hard to do the same with
the incubating Commons RDF proposal [1]. The reply on the list was that we
will worry about that later, but in my opinion this shows a fundamental
limitation of the current approach.

Besides the SPARQL usecase, here's a simple usecase for wrapping data as
RDF:

interface Person {
   String getFirstName();
   String getLastName();
   String getDiary()
}

interface DataBase() {
  Interator<Person> list();
  Interator<Person> filterByLastName(String);
  Interator<Person> filterByFirstName(String);
}

No the task is to expose this dynamically as RDF (i.e. without duplicating
the data).

Wrapping this with clerezza one would wrap the Person instance in a
blanknode, the identity of the BlankNode would depend on the identity of
the Person instance. Doing the same with the incubating commons rdf
proposal would require keeping a Bidirectional Weak Hashmap of from
Blanknode identifiers to Person objects. I don't think many programmers
would like to do the latter, so I don't think it is currently a suitable
API for exposing arbitrary data using the RDF datamodel.

Cheers,
Reto

1.
http://mail-archives.apache.org/mod_mbox/commonsrdf-dev/201503.mbox/%3CCALvhUEXSSwO-Udj6ngdedVQuPC6n=+983UbnkYoBs2psY5kURg@mail.gmail.com%3E

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Peter Ansell <an...@gmail.com>.
On 11 April 2015 at 22:11, Reto Gmür <re...@apache.org> wrote:
> On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter <br...@apache.org> wrote:
>
>> Hello Reto,
>>
>> 2015-03-30 14:45 GMT+02:00 Reto Gmür <re...@apache.org>:
>>
>> > Hi all,
>> >
>> > The clerezza commons RDF proposal that was in the sandbox and is now in
>> the
>> > clerezza-rdf-core repository has been changed to use
>> > org.apache.clerezza.commons-rdf.
>> >
>> > As you know if all goes well clerezza will be based in the result of the
>> > incubating project. If however this project should unfortunately not lead
>> > to something generic enough to be used for interfacing arbitrary data as
>> > RDF and thus be usable for clerezza, then clerezza might reactivate its
>> > commons-rdf proposal. It would then be up to commons to decide which
>> > proposal to adopt and under which name.
>> >
>>
>> We (the Apache Commons community) have already stated, that we don't have
>> the necessary knowledge about RDF to make such a decision. I would prefer
>> more people from clerezza joining this ML and build consensus with the
>> incubating commons rdf community about how an implementation of the RDF
>> specification should look like.
>>
>
> It might be hard to reach an acceptable solution if the result of one year
> on Github are taken as unmodifiable except when there is 100% agreement on
> a change.

You were privy to all of the public discussions on GitHub, and many of
the private discussions just before setting up the project publicly.
Please do not imply that this was your first opportunity to bring up
these issues, or that we had not responded at all to the issues you
did bring up in the past.

Apart from the structural constraints of having an entire interface
driven API, and there being no clear reason why the interface names
themselves should be changed to suit you, do you have other issues
where getting ~100 percent agreement has failed and you would like
some further discussion.

> Even without having the commons community diving deep into RDF it might
> become clear that one API is better suited for triple stores and their
> requirement while the other is more suitable to exposing arbitrary data
> source using the RDF model. So if the result is not something that can be
> used in all usecases having two commons project relating to RDF but with an
> distinct goal might also be an option.

If you could articulate why the current interface based method makes
it unsuitable for your use cases it would definitely help. In
particular, some examples of where Clerezza could map a data source to
RDF somewhow, but it would be impossible with commons-rdf-api, then we
can start to discuss it further. Right now you have only implied that
the difficulty exists without articulating it.

Thanks,

Peter

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Peter Ansell <an...@gmail.com>.
On 11 April 2015 at 22:11, Reto Gmür <re...@apache.org> wrote:
> On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter <br...@apache.org> wrote:
>
>> Hello Reto,
>>
>> 2015-03-30 14:45 GMT+02:00 Reto Gmür <re...@apache.org>:
>>
>> > Hi all,
>> >
>> > The clerezza commons RDF proposal that was in the sandbox and is now in
>> the
>> > clerezza-rdf-core repository has been changed to use
>> > org.apache.clerezza.commons-rdf.
>> >
>> > As you know if all goes well clerezza will be based in the result of the
>> > incubating project. If however this project should unfortunately not lead
>> > to something generic enough to be used for interfacing arbitrary data as
>> > RDF and thus be usable for clerezza, then clerezza might reactivate its
>> > commons-rdf proposal. It would then be up to commons to decide which
>> > proposal to adopt and under which name.
>> >
>>
>> We (the Apache Commons community) have already stated, that we don't have
>> the necessary knowledge about RDF to make such a decision. I would prefer
>> more people from clerezza joining this ML and build consensus with the
>> incubating commons rdf community about how an implementation of the RDF
>> specification should look like.
>>
>
> It might be hard to reach an acceptable solution if the result of one year
> on Github are taken as unmodifiable except when there is 100% agreement on
> a change.

You were privy to all of the public discussions on GitHub, and many of
the private discussions just before setting up the project publicly.
Please do not imply that this was your first opportunity to bring up
these issues, or that we had not responded at all to the issues you
did bring up in the past.

Apart from the structural constraints of having an entire interface
driven API, and there being no clear reason why the interface names
themselves should be changed to suit you, do you have other issues
where getting ~100 percent agreement has failed and you would like
some further discussion.

> Even without having the commons community diving deep into RDF it might
> become clear that one API is better suited for triple stores and their
> requirement while the other is more suitable to exposing arbitrary data
> source using the RDF model. So if the result is not something that can be
> used in all usecases having two commons project relating to RDF but with an
> distinct goal might also be an option.

If you could articulate why the current interface based method makes
it unsuitable for your use cases it would definitely help. In
particular, some examples of where Clerezza could map a data source to
RDF somewhow, but it would be impossible with commons-rdf-api, then we
can start to discuss it further. Right now you have only implied that
the difficulty exists without articulating it.

Thanks,

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter <br...@apache.org> wrote:

> Hello Reto,
>
> 2015-03-30 14:45 GMT+02:00 Reto Gmür <re...@apache.org>:
>
> > Hi all,
> >
> > The clerezza commons RDF proposal that was in the sandbox and is now in
> the
> > clerezza-rdf-core repository has been changed to use
> > org.apache.clerezza.commons-rdf.
> >
> > As you know if all goes well clerezza will be based in the result of the
> > incubating project. If however this project should unfortunately not lead
> > to something generic enough to be used for interfacing arbitrary data as
> > RDF and thus be usable for clerezza, then clerezza might reactivate its
> > commons-rdf proposal. It would then be up to commons to decide which
> > proposal to adopt and under which name.
> >
>
> We (the Apache Commons community) have already stated, that we don't have
> the necessary knowledge about RDF to make such a decision. I would prefer
> more people from clerezza joining this ML and build consensus with the
> incubating commons rdf community about how an implementation of the RDF
> specification should look like.
>

It might be hard to reach an acceptable solution if the result of one year
on Github are taken as unmodifiable except when there is 100% agreement on
a change.

Even without having the commons community diving deep into RDF it might
become clear that one API is better suited for triple stores and their
requirement while the other is more suitable to exposing arbitrary data
source using the RDF model. So if the result is not something that can be
used in all usecases having two commons project relating to RDF but with an
distinct goal might also be an option.

Cheers,
Reto


>
>
> >
> > Till then I would prefer this project to use a group ID outside
> > org.apache.commons.
> >
>
> Yes it would probably be better to resolve this conflict and build
> consensus before publishing artifacts under the commons group id.
>
> Benedikt
>
>
> >
> > Cheers,
> > Reto
> > Hi all,
> > all this looks sensible to me.
> >
> > cheers,
> > Enrico
> > --
> > Enrico Daga
> > http://about.me/enridaga
> >
> >
> > On 29 March 2015 at 17:25, Sergio Fernández <wi...@apache.org> wrote:
> > > On 28/03/15 17:40, Benedikt Ritter wrote:
> > >>
> > >> So for Commons RDF I would recommend the following:
> > >>
> > >> parent:
> > >>    org.apache.commons:commons-rdf-parent
> > >> api:
> > >>    org.apache.commons:commons-rdf-api
> > >> impl:
> > >>    org.apache.commons:commons-rdf-impl
> > >>
> > >> Would that work for you?
> > >
> > >
> > > Yes, it does.
> > >
> > > I've just implemented it (commit
> > 1296de032601ada0d244cca51591d6eeeba449cc).
> > >
> > > I'd like to ask: does it work for everybody?
> > >
> > >
> > > --
> > > Sergio Fernández
> > > Partner Technology Manager
> > > Redlink GmbH
> > > m: +43 660 2747 925
> > > e: sergio.fernandez@redlink.co
> > > w: http://redlink.co
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter <br...@apache.org> wrote:

> Hello Reto,
>
> 2015-03-30 14:45 GMT+02:00 Reto Gmür <re...@apache.org>:
>
> > Hi all,
> >
> > The clerezza commons RDF proposal that was in the sandbox and is now in
> the
> > clerezza-rdf-core repository has been changed to use
> > org.apache.clerezza.commons-rdf.
> >
> > As you know if all goes well clerezza will be based in the result of the
> > incubating project. If however this project should unfortunately not lead
> > to something generic enough to be used for interfacing arbitrary data as
> > RDF and thus be usable for clerezza, then clerezza might reactivate its
> > commons-rdf proposal. It would then be up to commons to decide which
> > proposal to adopt and under which name.
> >
>
> We (the Apache Commons community) have already stated, that we don't have
> the necessary knowledge about RDF to make such a decision. I would prefer
> more people from clerezza joining this ML and build consensus with the
> incubating commons rdf community about how an implementation of the RDF
> specification should look like.
>

It might be hard to reach an acceptable solution if the result of one year
on Github are taken as unmodifiable except when there is 100% agreement on
a change.

Even without having the commons community diving deep into RDF it might
become clear that one API is better suited for triple stores and their
requirement while the other is more suitable to exposing arbitrary data
source using the RDF model. So if the result is not something that can be
used in all usecases having two commons project relating to RDF but with an
distinct goal might also be an option.

Cheers,
Reto


>
>
> >
> > Till then I would prefer this project to use a group ID outside
> > org.apache.commons.
> >
>
> Yes it would probably be better to resolve this conflict and build
> consensus before publishing artifacts under the commons group id.
>
> Benedikt
>
>
> >
> > Cheers,
> > Reto
> > Hi all,
> > all this looks sensible to me.
> >
> > cheers,
> > Enrico
> > --
> > Enrico Daga
> > http://about.me/enridaga
> >
> >
> > On 29 March 2015 at 17:25, Sergio Fernández <wi...@apache.org> wrote:
> > > On 28/03/15 17:40, Benedikt Ritter wrote:
> > >>
> > >> So for Commons RDF I would recommend the following:
> > >>
> > >> parent:
> > >>    org.apache.commons:commons-rdf-parent
> > >> api:
> > >>    org.apache.commons:commons-rdf-api
> > >> impl:
> > >>    org.apache.commons:commons-rdf-impl
> > >>
> > >> Would that work for you?
> > >
> > >
> > > Yes, it does.
> > >
> > > I've just implemented it (commit
> > 1296de032601ada0d244cca51591d6eeeba449cc).
> > >
> > > I'd like to ask: does it work for everybody?
> > >
> > >
> > > --
> > > Sergio Fernández
> > > Partner Technology Manager
> > > Redlink GmbH
> > > m: +43 660 2747 925
> > > e: sergio.fernandez@redlink.co
> > > w: http://redlink.co
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Benedikt Ritter <br...@apache.org>.
Hello Reto,

2015-03-30 14:45 GMT+02:00 Reto Gmür <re...@apache.org>:

> Hi all,
>
> The clerezza commons RDF proposal that was in the sandbox and is now in the
> clerezza-rdf-core repository has been changed to use
> org.apache.clerezza.commons-rdf.
>
> As you know if all goes well clerezza will be based in the result of the
> incubating project. If however this project should unfortunately not lead
> to something generic enough to be used for interfacing arbitrary data as
> RDF and thus be usable for clerezza, then clerezza might reactivate its
> commons-rdf proposal. It would then be up to commons to decide which
> proposal to adopt and under which name.
>

We (the Apache Commons community) have already stated, that we don't have
the necessary knowledge about RDF to make such a decision. I would prefer
more people from clerezza joining this ML and build consensus with the
incubating commons rdf community about how an implementation of the RDF
specification should look like.


>
> Till then I would prefer this project to use a group ID outside
> org.apache.commons.
>

Yes it would probably be better to resolve this conflict and build
consensus before publishing artifacts under the commons group id.

Benedikt


>
> Cheers,
> Reto
> Hi all,
> all this looks sensible to me.
>
> cheers,
> Enrico
> --
> Enrico Daga
> http://about.me/enridaga
>
>
> On 29 March 2015 at 17:25, Sergio Fernández <wi...@apache.org> wrote:
> > On 28/03/15 17:40, Benedikt Ritter wrote:
> >>
> >> So for Commons RDF I would recommend the following:
> >>
> >> parent:
> >>    org.apache.commons:commons-rdf-parent
> >> api:
> >>    org.apache.commons:commons-rdf-api
> >> impl:
> >>    org.apache.commons:commons-rdf-impl
> >>
> >> Would that work for you?
> >
> >
> > Yes, it does.
> >
> > I've just implemented it (commit
> 1296de032601ada0d244cca51591d6eeeba449cc).
> >
> > I'd like to ask: does it work for everybody?
> >
> >
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: sergio.fernandez@redlink.co
> > w: http://redlink.co
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Peter Ansell <an...@gmail.com>.
On 30 March 2015 at 23:45, Reto Gmür <re...@apache.org> wrote:
> Hi all,
>
> The clerezza commons RDF proposal that was in the sandbox and is now in the
> clerezza-rdf-core repository has been changed to use
> org.apache.clerezza.commons-rdf.
>
> As you know if all goes well clerezza will be based in the result of the
> incubating project. If however this project should unfortunately not lead
> to something generic enough to be used for interfacing arbitrary data as
> RDF and thus be usable for clerezza, then clerezza might reactivate its
> commons-rdf proposal. It would then be up to commons to decide which
> proposal to adopt and under which name.

The project is not designed with "interfacing arbitrary data as RDF"
in mind, so it is unlikely it will suit Clerezza if that is what you
are aiming for Clerezza Commons RDF to do for its internal purposes.
It is aimed at representing the RDF-1.1 Abstract Data Model using Java
interfaces. Designing around interfaces should theoretically be the
lowest common denominator for attaching to any existing project, and
it isn't clear why it wouldn't work for you. Also keep in mind that we
are not expecting any project to internally rely on the API we are
providing here. The main goal is interoperability at the external
facing parts of each implementation, not changing the core models that
each implementation uses internally.

What exactly do you mean by "reactivate" the clerezza commons-rdf
proposal? All that happened previously was that you followed the
Commons suggestion for any Apache committer to unilaterally add
modules arbitrarily to Apache Commons. There was, and is, no bilateral
support for your actions and threatening to propose an alternative,
again......

> Till then I would prefer this project to use a group ID outside
> org.apache.commons.

We should probably resolve this now. There is no point to changing the
group ID in the future and Reto has threatened an alternative (again)
to support the proposal to not have this project use the standard
convention.

Peter

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Peter Ansell <an...@gmail.com>.
On 30 March 2015 at 23:45, Reto Gmür <re...@apache.org> wrote:
> Hi all,
>
> The clerezza commons RDF proposal that was in the sandbox and is now in the
> clerezza-rdf-core repository has been changed to use
> org.apache.clerezza.commons-rdf.
>
> As you know if all goes well clerezza will be based in the result of the
> incubating project. If however this project should unfortunately not lead
> to something generic enough to be used for interfacing arbitrary data as
> RDF and thus be usable for clerezza, then clerezza might reactivate its
> commons-rdf proposal. It would then be up to commons to decide which
> proposal to adopt and under which name.

The project is not designed with "interfacing arbitrary data as RDF"
in mind, so it is unlikely it will suit Clerezza if that is what you
are aiming for Clerezza Commons RDF to do for its internal purposes.
It is aimed at representing the RDF-1.1 Abstract Data Model using Java
interfaces. Designing around interfaces should theoretically be the
lowest common denominator for attaching to any existing project, and
it isn't clear why it wouldn't work for you. Also keep in mind that we
are not expecting any project to internally rely on the API we are
providing here. The main goal is interoperability at the external
facing parts of each implementation, not changing the core models that
each implementation uses internally.

What exactly do you mean by "reactivate" the clerezza commons-rdf
proposal? All that happened previously was that you followed the
Commons suggestion for any Apache committer to unilaterally add
modules arbitrarily to Apache Commons. There was, and is, no bilateral
support for your actions and threatening to propose an alternative,
again......

> Till then I would prefer this project to use a group ID outside
> org.apache.commons.

We should probably resolve this now. There is no point to changing the
group ID in the future and Reto has threatened an alternative (again)
to support the proposal to not have this project use the standard
convention.

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Benedikt Ritter <br...@apache.org>.
Hello Reto,

2015-03-30 14:45 GMT+02:00 Reto Gmür <re...@apache.org>:

> Hi all,
>
> The clerezza commons RDF proposal that was in the sandbox and is now in the
> clerezza-rdf-core repository has been changed to use
> org.apache.clerezza.commons-rdf.
>
> As you know if all goes well clerezza will be based in the result of the
> incubating project. If however this project should unfortunately not lead
> to something generic enough to be used for interfacing arbitrary data as
> RDF and thus be usable for clerezza, then clerezza might reactivate its
> commons-rdf proposal. It would then be up to commons to decide which
> proposal to adopt and under which name.
>

We (the Apache Commons community) have already stated, that we don't have
the necessary knowledge about RDF to make such a decision. I would prefer
more people from clerezza joining this ML and build consensus with the
incubating commons rdf community about how an implementation of the RDF
specification should look like.


>
> Till then I would prefer this project to use a group ID outside
> org.apache.commons.
>

Yes it would probably be better to resolve this conflict and build
consensus before publishing artifacts under the commons group id.

Benedikt


>
> Cheers,
> Reto
> Hi all,
> all this looks sensible to me.
>
> cheers,
> Enrico
> --
> Enrico Daga
> http://about.me/enridaga
>
>
> On 29 March 2015 at 17:25, Sergio Fernández <wi...@apache.org> wrote:
> > On 28/03/15 17:40, Benedikt Ritter wrote:
> >>
> >> So for Commons RDF I would recommend the following:
> >>
> >> parent:
> >>    org.apache.commons:commons-rdf-parent
> >> api:
> >>    org.apache.commons:commons-rdf-api
> >> impl:
> >>    org.apache.commons:commons-rdf-impl
> >>
> >> Would that work for you?
> >
> >
> > Yes, it does.
> >
> > I've just implemented it (commit
> 1296de032601ada0d244cca51591d6eeeba449cc).
> >
> > I'd like to ask: does it work for everybody?
> >
> >
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: sergio.fernandez@redlink.co
> > w: http://redlink.co
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
Hi all,

The clerezza commons RDF proposal that was in the sandbox and is now in the
clerezza-rdf-core repository has been changed to use
org.apache.clerezza.commons-rdf.

As you know if all goes well clerezza will be based in the result of the
incubating project. If however this project should unfortunately not lead
to something generic enough to be used for interfacing arbitrary data as
RDF and thus be usable for clerezza, then clerezza might reactivate its
commons-rdf proposal. It would then be up to commons to decide which
proposal to adopt and under which name.

Till then I would prefer this project to use a group ID outside
org.apache.commons.

Cheers,
Reto
Hi all,
all this looks sensible to me.

cheers,
Enrico
--
Enrico Daga
http://about.me/enridaga


On 29 March 2015 at 17:25, Sergio Fernández <wi...@apache.org> wrote:
> On 28/03/15 17:40, Benedikt Ritter wrote:
>>
>> So for Commons RDF I would recommend the following:
>>
>> parent:
>>    org.apache.commons:commons-rdf-parent
>> api:
>>    org.apache.commons:commons-rdf-api
>> impl:
>>    org.apache.commons:commons-rdf-impl
>>
>> Would that work for you?
>
>
> Yes, it does.
>
> I've just implemented it (commit
1296de032601ada0d244cca51591d6eeeba449cc).
>
> I'd like to ask: does it work for everybody?
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Reto Gmür <re...@apache.org>.
Hi all,

The clerezza commons RDF proposal that was in the sandbox and is now in the
clerezza-rdf-core repository has been changed to use
org.apache.clerezza.commons-rdf.

As you know if all goes well clerezza will be based in the result of the
incubating project. If however this project should unfortunately not lead
to something generic enough to be used for interfacing arbitrary data as
RDF and thus be usable for clerezza, then clerezza might reactivate its
commons-rdf proposal. It would then be up to commons to decide which
proposal to adopt and under which name.

Till then I would prefer this project to use a group ID outside
org.apache.commons.

Cheers,
Reto
Hi all,
all this looks sensible to me.

cheers,
Enrico
--
Enrico Daga
http://about.me/enridaga


On 29 March 2015 at 17:25, Sergio Fernández <wi...@apache.org> wrote:
> On 28/03/15 17:40, Benedikt Ritter wrote:
>>
>> So for Commons RDF I would recommend the following:
>>
>> parent:
>>    org.apache.commons:commons-rdf-parent
>> api:
>>    org.apache.commons:commons-rdf-api
>> impl:
>>    org.apache.commons:commons-rdf-impl
>>
>> Would that work for you?
>
>
> Yes, it does.
>
> I've just implemented it (commit
1296de032601ada0d244cca51591d6eeeba449cc).
>
> I'd like to ask: does it work for everybody?
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Enrico Daga <en...@gmail.com>.
Hi all,
all this looks sensible to me.

cheers,
Enrico
--
Enrico Daga
http://about.me/enridaga


On 29 March 2015 at 17:25, Sergio Fernández <wi...@apache.org> wrote:
> On 28/03/15 17:40, Benedikt Ritter wrote:
>>
>> So for Commons RDF I would recommend the following:
>>
>> parent:
>>    org.apache.commons:commons-rdf-parent
>> api:
>>    org.apache.commons:commons-rdf-api
>> impl:
>>    org.apache.commons:commons-rdf-impl
>>
>> Would that work for you?
>
>
> Yes, it does.
>
> I've just implemented it (commit 1296de032601ada0d244cca51591d6eeeba449cc).
>
> I'd like to ask: does it work for everybody?
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Enrico Daga <en...@gmail.com>.
Hi all,
all this looks sensible to me.

cheers,
Enrico
--
Enrico Daga
http://about.me/enridaga


On 29 March 2015 at 17:25, Sergio Fernández <wi...@apache.org> wrote:
> On 28/03/15 17:40, Benedikt Ritter wrote:
>>
>> So for Commons RDF I would recommend the following:
>>
>> parent:
>>    org.apache.commons:commons-rdf-parent
>> api:
>>    org.apache.commons:commons-rdf-api
>> impl:
>>    org.apache.commons:commons-rdf-impl
>>
>> Would that work for you?
>
>
> Yes, it does.
>
> I've just implemented it (commit 1296de032601ada0d244cca51591d6eeeba449cc).
>
> I'd like to ask: does it work for everybody?
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Sergio Fernández <wi...@apache.org>.
On 28/03/15 17:40, Benedikt Ritter wrote:
> So for Commons RDF I would recommend the following:
>
> parent:
>    org.apache.commons:commons-rdf-parent
> api:
>    org.apache.commons:commons-rdf-api
> impl:
>    org.apache.commons:commons-rdf-impl
>
> Would that work for you?

Yes, it does.

I've just implemented it (commit 1296de032601ada0d244cca51591d6eeeba449cc).

I'd like to ask: does it work for everybody?

-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Sergio Fernández <wi...@apache.org>.
On 28/03/15 17:40, Benedikt Ritter wrote:
> So for Commons RDF I would recommend the following:
>
> parent:
>    org.apache.commons:commons-rdf-parent
> api:
>    org.apache.commons:commons-rdf-api
> impl:
>    org.apache.commons:commons-rdf-impl
>
> Would that work for you?

Yes, it does.

I've just implemented it (commit 1296de032601ada0d244cca51591d6eeeba449cc).

I'd like to ask: does it work for everybody?

-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Stian Soiland-Reyes <st...@apache.org>.
I generally prefer one groupId matching the git repository somehow (e.g.
org.apache.commons.rdf), but +1 to the below and be aligned with the rest
of (modern) Commons. Also we won't have that many modules.
On 28 Mar 2015 16:51, "Gary Gregory" <ga...@gmail.com> wrote:

> On Sat, Mar 28, 2015 at 9:40 AM, Benedikt Ritter <br...@apache.org>
> wrote:
>
> > 2015-03-28 16:37 GMT+01:00 Sergio Fernández <wi...@apache.org>:
> >
> > > Hi Benedikt,
> > >
> > > that question came to me while working on COMMONSRDF-2...
> > >
> > > Personally I see Apache Commons as our current target for graduation.
> > > Therefore I'd prefer to use those coordinates already in incubation
> > (that's
> > > considered a best practices to avoid issues on graduation). But of
> course
> > > anybody else could have other opinion.
> > >
> > > In that case, how does Commons manages different artifacts per
> component?
> > > Because we currently have three (parent, api and simple imp). So my
> idea
> > > was to put all together under org.apache.commons.rdf groupId, but we
> can
> > > also stay at org.apache.commons and solve it at the artifacts' level.
> > >
> >
> >
> > Apache Commons VFS 2 uses the following pattern [1]:
> >
> > parent:
> >   org.apache.commons:commons-vfs-2-project
> > core:
> >   org.apache.commons:commons-vfs-2
> > examples:
> >   org.apache.commons:commons-vfs-2-examples
> >
> > So for Commons RDF I would recommend the following:
> >
> > parent:
> >   org.apache.commons:commons-rdf-parent
> > api:
> >   org.apache.commons:commons-rdf-api
> > impl:
> >   org.apache.commons:commons-rdf-impl
> >
> > Would that work for you?
> >
>
> Looks good to me.
>
> G
>
> >
> > Benedikt
> >
> > [1] https://github.com/apache/commons-vfs
> >
> >
> > >
> > > Thanks for bringing here this discussion and your valuable feedback.
> > >
> > > Cheers,
> > >
> > >
> > > On 28/03/15 14:13, Benedikt Ritter wrote:
> > >
> > >> Hi guys,
> > >>
> > >> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates
> > for
> > >> incubation releases of Commons RDF. I may have missed something, but
> my
> > >> last information was, that Commons RDF has not yet decided whether it
> > >> want's to join Apache Commons or go TLP in the end. So the situation
> > looks
> > >> like the following to me:
> > >>
> > >> As long as Commons RDF has not decided to join Apache Commons in the
> > end,
> > >> Commons RDF should not use the Apache Commons groupid. So maven
> > >> coordinates
> > >> should be:
> > >>
> > >> <groupid>org.apache.commonsrdf</groupid>
> > >> <artifactid>commons-rdf</artifactid>
> > >>
> > >> If Commons RDF has already decided not to go TLP and to join Apache
> > >> Commons
> > >> after incubation, the coordinates should be (have i missed that
> > decision?
> > >> Sorry!):
> > >>
> > >> <groupid>org.apache.commons</groupid>
> > >> <artifactid>commons-rdf</artifactid>
> > >>
> > >> Regards,
> > >> Benedikt
> > >>
> > >> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
> > >>
> > >>
> > > --
> > > Sergio Fernández
> > > Partner Technology Manager
> > > Redlink GmbH
> > > m: +43 660 2747 925
> > > e: sergio.fernandez@redlink.co
> > > w: http://redlink.co
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Stian Soiland-Reyes <st...@apache.org>.
I generally prefer one groupId matching the git repository somehow (e.g.
org.apache.commons.rdf), but +1 to the below and be aligned with the rest
of (modern) Commons. Also we won't have that many modules.
On 28 Mar 2015 16:51, "Gary Gregory" <ga...@gmail.com> wrote:

> On Sat, Mar 28, 2015 at 9:40 AM, Benedikt Ritter <br...@apache.org>
> wrote:
>
> > 2015-03-28 16:37 GMT+01:00 Sergio Fernández <wi...@apache.org>:
> >
> > > Hi Benedikt,
> > >
> > > that question came to me while working on COMMONSRDF-2...
> > >
> > > Personally I see Apache Commons as our current target for graduation.
> > > Therefore I'd prefer to use those coordinates already in incubation
> > (that's
> > > considered a best practices to avoid issues on graduation). But of
> course
> > > anybody else could have other opinion.
> > >
> > > In that case, how does Commons manages different artifacts per
> component?
> > > Because we currently have three (parent, api and simple imp). So my
> idea
> > > was to put all together under org.apache.commons.rdf groupId, but we
> can
> > > also stay at org.apache.commons and solve it at the artifacts' level.
> > >
> >
> >
> > Apache Commons VFS 2 uses the following pattern [1]:
> >
> > parent:
> >   org.apache.commons:commons-vfs-2-project
> > core:
> >   org.apache.commons:commons-vfs-2
> > examples:
> >   org.apache.commons:commons-vfs-2-examples
> >
> > So for Commons RDF I would recommend the following:
> >
> > parent:
> >   org.apache.commons:commons-rdf-parent
> > api:
> >   org.apache.commons:commons-rdf-api
> > impl:
> >   org.apache.commons:commons-rdf-impl
> >
> > Would that work for you?
> >
>
> Looks good to me.
>
> G
>
> >
> > Benedikt
> >
> > [1] https://github.com/apache/commons-vfs
> >
> >
> > >
> > > Thanks for bringing here this discussion and your valuable feedback.
> > >
> > > Cheers,
> > >
> > >
> > > On 28/03/15 14:13, Benedikt Ritter wrote:
> > >
> > >> Hi guys,
> > >>
> > >> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates
> > for
> > >> incubation releases of Commons RDF. I may have missed something, but
> my
> > >> last information was, that Commons RDF has not yet decided whether it
> > >> want's to join Apache Commons or go TLP in the end. So the situation
> > looks
> > >> like the following to me:
> > >>
> > >> As long as Commons RDF has not decided to join Apache Commons in the
> > end,
> > >> Commons RDF should not use the Apache Commons groupid. So maven
> > >> coordinates
> > >> should be:
> > >>
> > >> <groupid>org.apache.commonsrdf</groupid>
> > >> <artifactid>commons-rdf</artifactid>
> > >>
> > >> If Commons RDF has already decided not to go TLP and to join Apache
> > >> Commons
> > >> after incubation, the coordinates should be (have i missed that
> > decision?
> > >> Sorry!):
> > >>
> > >> <groupid>org.apache.commons</groupid>
> > >> <artifactid>commons-rdf</artifactid>
> > >>
> > >> Regards,
> > >> Benedikt
> > >>
> > >> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
> > >>
> > >>
> > > --
> > > Sergio Fernández
> > > Partner Technology Manager
> > > Redlink GmbH
> > > m: +43 660 2747 925
> > > e: sergio.fernandez@redlink.co
> > > w: http://redlink.co
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Mar 28, 2015 at 9:40 AM, Benedikt Ritter <br...@apache.org> wrote:

> 2015-03-28 16:37 GMT+01:00 Sergio Fernández <wi...@apache.org>:
>
> > Hi Benedikt,
> >
> > that question came to me while working on COMMONSRDF-2...
> >
> > Personally I see Apache Commons as our current target for graduation.
> > Therefore I'd prefer to use those coordinates already in incubation
> (that's
> > considered a best practices to avoid issues on graduation). But of course
> > anybody else could have other opinion.
> >
> > In that case, how does Commons manages different artifacts per component?
> > Because we currently have three (parent, api and simple imp). So my idea
> > was to put all together under org.apache.commons.rdf groupId, but we can
> > also stay at org.apache.commons and solve it at the artifacts' level.
> >
>
>
> Apache Commons VFS 2 uses the following pattern [1]:
>
> parent:
>   org.apache.commons:commons-vfs-2-project
> core:
>   org.apache.commons:commons-vfs-2
> examples:
>   org.apache.commons:commons-vfs-2-examples
>
> So for Commons RDF I would recommend the following:
>
> parent:
>   org.apache.commons:commons-rdf-parent
> api:
>   org.apache.commons:commons-rdf-api
> impl:
>   org.apache.commons:commons-rdf-impl
>
> Would that work for you?
>

Looks good to me.

G

>
> Benedikt
>
> [1] https://github.com/apache/commons-vfs
>
>
> >
> > Thanks for bringing here this discussion and your valuable feedback.
> >
> > Cheers,
> >
> >
> > On 28/03/15 14:13, Benedikt Ritter wrote:
> >
> >> Hi guys,
> >>
> >> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates
> for
> >> incubation releases of Commons RDF. I may have missed something, but my
> >> last information was, that Commons RDF has not yet decided whether it
> >> want's to join Apache Commons or go TLP in the end. So the situation
> looks
> >> like the following to me:
> >>
> >> As long as Commons RDF has not decided to join Apache Commons in the
> end,
> >> Commons RDF should not use the Apache Commons groupid. So maven
> >> coordinates
> >> should be:
> >>
> >> <groupid>org.apache.commonsrdf</groupid>
> >> <artifactid>commons-rdf</artifactid>
> >>
> >> If Commons RDF has already decided not to go TLP and to join Apache
> >> Commons
> >> after incubation, the coordinates should be (have i missed that
> decision?
> >> Sorry!):
> >>
> >> <groupid>org.apache.commons</groupid>
> >> <artifactid>commons-rdf</artifactid>
> >>
> >> Regards,
> >> Benedikt
> >>
> >> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
> >>
> >>
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: sergio.fernandez@redlink.co
> > w: http://redlink.co
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Mar 28, 2015 at 9:40 AM, Benedikt Ritter <br...@apache.org> wrote:

> 2015-03-28 16:37 GMT+01:00 Sergio Fernández <wi...@apache.org>:
>
> > Hi Benedikt,
> >
> > that question came to me while working on COMMONSRDF-2...
> >
> > Personally I see Apache Commons as our current target for graduation.
> > Therefore I'd prefer to use those coordinates already in incubation
> (that's
> > considered a best practices to avoid issues on graduation). But of course
> > anybody else could have other opinion.
> >
> > In that case, how does Commons manages different artifacts per component?
> > Because we currently have three (parent, api and simple imp). So my idea
> > was to put all together under org.apache.commons.rdf groupId, but we can
> > also stay at org.apache.commons and solve it at the artifacts' level.
> >
>
>
> Apache Commons VFS 2 uses the following pattern [1]:
>
> parent:
>   org.apache.commons:commons-vfs-2-project
> core:
>   org.apache.commons:commons-vfs-2
> examples:
>   org.apache.commons:commons-vfs-2-examples
>
> So for Commons RDF I would recommend the following:
>
> parent:
>   org.apache.commons:commons-rdf-parent
> api:
>   org.apache.commons:commons-rdf-api
> impl:
>   org.apache.commons:commons-rdf-impl
>
> Would that work for you?
>

Looks good to me.

G

>
> Benedikt
>
> [1] https://github.com/apache/commons-vfs
>
>
> >
> > Thanks for bringing here this discussion and your valuable feedback.
> >
> > Cheers,
> >
> >
> > On 28/03/15 14:13, Benedikt Ritter wrote:
> >
> >> Hi guys,
> >>
> >> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates
> for
> >> incubation releases of Commons RDF. I may have missed something, but my
> >> last information was, that Commons RDF has not yet decided whether it
> >> want's to join Apache Commons or go TLP in the end. So the situation
> looks
> >> like the following to me:
> >>
> >> As long as Commons RDF has not decided to join Apache Commons in the
> end,
> >> Commons RDF should not use the Apache Commons groupid. So maven
> >> coordinates
> >> should be:
> >>
> >> <groupid>org.apache.commonsrdf</groupid>
> >> <artifactid>commons-rdf</artifactid>
> >>
> >> If Commons RDF has already decided not to go TLP and to join Apache
> >> Commons
> >> after incubation, the coordinates should be (have i missed that
> decision?
> >> Sorry!):
> >>
> >> <groupid>org.apache.commons</groupid>
> >> <artifactid>commons-rdf</artifactid>
> >>
> >> Regards,
> >> Benedikt
> >>
> >> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
> >>
> >>
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: sergio.fernandez@redlink.co
> > w: http://redlink.co
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Benedikt Ritter <br...@apache.org>.
2015-03-28 16:37 GMT+01:00 Sergio Fernández <wi...@apache.org>:

> Hi Benedikt,
>
> that question came to me while working on COMMONSRDF-2...
>
> Personally I see Apache Commons as our current target for graduation.
> Therefore I'd prefer to use those coordinates already in incubation (that's
> considered a best practices to avoid issues on graduation). But of course
> anybody else could have other opinion.
>
> In that case, how does Commons manages different artifacts per component?
> Because we currently have three (parent, api and simple imp). So my idea
> was to put all together under org.apache.commons.rdf groupId, but we can
> also stay at org.apache.commons and solve it at the artifacts' level.
>


Apache Commons VFS 2 uses the following pattern [1]:

parent:
  org.apache.commons:commons-vfs-2-project
core:
  org.apache.commons:commons-vfs-2
examples:
  org.apache.commons:commons-vfs-2-examples

So for Commons RDF I would recommend the following:

parent:
  org.apache.commons:commons-rdf-parent
api:
  org.apache.commons:commons-rdf-api
impl:
  org.apache.commons:commons-rdf-impl

Would that work for you?

Benedikt

[1] https://github.com/apache/commons-vfs


>
> Thanks for bringing here this discussion and your valuable feedback.
>
> Cheers,
>
>
> On 28/03/15 14:13, Benedikt Ritter wrote:
>
>> Hi guys,
>>
>> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates for
>> incubation releases of Commons RDF. I may have missed something, but my
>> last information was, that Commons RDF has not yet decided whether it
>> want's to join Apache Commons or go TLP in the end. So the situation looks
>> like the following to me:
>>
>> As long as Commons RDF has not decided to join Apache Commons in the end,
>> Commons RDF should not use the Apache Commons groupid. So maven
>> coordinates
>> should be:
>>
>> <groupid>org.apache.commonsrdf</groupid>
>> <artifactid>commons-rdf</artifactid>
>>
>> If Commons RDF has already decided not to go TLP and to join Apache
>> Commons
>> after incubation, the coordinates should be (have i missed that decision?
>> Sorry!):
>>
>> <groupid>org.apache.commons</groupid>
>> <artifactid>commons-rdf</artifactid>
>>
>> Regards,
>> Benedikt
>>
>> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
>>
>>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Benedikt Ritter <br...@apache.org>.
2015-03-28 16:37 GMT+01:00 Sergio Fernández <wi...@apache.org>:

> Hi Benedikt,
>
> that question came to me while working on COMMONSRDF-2...
>
> Personally I see Apache Commons as our current target for graduation.
> Therefore I'd prefer to use those coordinates already in incubation (that's
> considered a best practices to avoid issues on graduation). But of course
> anybody else could have other opinion.
>
> In that case, how does Commons manages different artifacts per component?
> Because we currently have three (parent, api and simple imp). So my idea
> was to put all together under org.apache.commons.rdf groupId, but we can
> also stay at org.apache.commons and solve it at the artifacts' level.
>


Apache Commons VFS 2 uses the following pattern [1]:

parent:
  org.apache.commons:commons-vfs-2-project
core:
  org.apache.commons:commons-vfs-2
examples:
  org.apache.commons:commons-vfs-2-examples

So for Commons RDF I would recommend the following:

parent:
  org.apache.commons:commons-rdf-parent
api:
  org.apache.commons:commons-rdf-api
impl:
  org.apache.commons:commons-rdf-impl

Would that work for you?

Benedikt

[1] https://github.com/apache/commons-vfs


>
> Thanks for bringing here this discussion and your valuable feedback.
>
> Cheers,
>
>
> On 28/03/15 14:13, Benedikt Ritter wrote:
>
>> Hi guys,
>>
>> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates for
>> incubation releases of Commons RDF. I may have missed something, but my
>> last information was, that Commons RDF has not yet decided whether it
>> want's to join Apache Commons or go TLP in the end. So the situation looks
>> like the following to me:
>>
>> As long as Commons RDF has not decided to join Apache Commons in the end,
>> Commons RDF should not use the Apache Commons groupid. So maven
>> coordinates
>> should be:
>>
>> <groupid>org.apache.commonsrdf</groupid>
>> <artifactid>commons-rdf</artifactid>
>>
>> If Commons RDF has already decided not to go TLP and to join Apache
>> Commons
>> after incubation, the coordinates should be (have i missed that decision?
>> Sorry!):
>>
>> <groupid>org.apache.commons</groupid>
>> <artifactid>commons-rdf</artifactid>
>>
>> Regards,
>> Benedikt
>>
>> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
>>
>>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Sergio Fernández <wi...@apache.org>.
Hi Benedikt,

that question came to me while working on COMMONSRDF-2...

Personally I see Apache Commons as our current target for graduation. 
Therefore I'd prefer to use those coordinates already in incubation 
(that's considered a best practices to avoid issues on graduation). But 
of course anybody else could have other opinion.

In that case, how does Commons manages different artifacts per 
component? Because we currently have three (parent, api and simple imp). 
So my idea was to put all together under org.apache.commons.rdf groupId, 
but we can also stay at org.apache.commons and solve it at the 
artifacts' level.

Thanks for bringing here this discussion and your valuable feedback.

Cheers,


On 28/03/15 14:13, Benedikt Ritter wrote:
> Hi guys,
>
> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates for
> incubation releases of Commons RDF. I may have missed something, but my
> last information was, that Commons RDF has not yet decided whether it
> want's to join Apache Commons or go TLP in the end. So the situation looks
> like the following to me:
>
> As long as Commons RDF has not decided to join Apache Commons in the end,
> Commons RDF should not use the Apache Commons groupid. So maven coordinates
> should be:
>
> <groupid>org.apache.commonsrdf</groupid>
> <artifactid>commons-rdf</artifactid>
>
> If Commons RDF has already decided not to go TLP and to join Apache Commons
> after incubation, the coordinates should be (have i missed that decision?
> Sorry!):
>
> <groupid>org.apache.commons</groupid>
> <artifactid>commons-rdf</artifactid>
>
> Regards,
> Benedikt
>
> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
>

-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Gary Gregory <ga...@gmail.com>.
Note your that you'll need one Maven module, POM, and groupid per jar you
release. At least that's how I would do it. It sounds like you are dealing
with a Maven multi-module project. Commons has at least one of those:
Commons JCS.

Gary

On Sat, Mar 28, 2015 at 6:13 AM, Benedikt Ritter <br...@apache.org> wrote:

> Hi guys,
>
> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates for
> incubation releases of Commons RDF. I may have missed something, but my
> last information was, that Commons RDF has not yet decided whether it
> want's to join Apache Commons or go TLP in the end. So the situation looks
> like the following to me:
>
> As long as Commons RDF has not decided to join Apache Commons in the end,
> Commons RDF should not use the Apache Commons groupid. So maven coordinates
> should be:
>
> <groupid>org.apache.commonsrdf</groupid>
> <artifactid>commons-rdf</artifactid>
>
> If Commons RDF has already decided not to go TLP and to join Apache Commons
> after incubation, the coordinates should be (have i missed that decision?
> Sorry!):
>
> <groupid>org.apache.commons</groupid>
> <artifactid>commons-rdf</artifactid>
>
> Regards,
> Benedikt
>
> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Sergio Fernández <wi...@apache.org>.
Hi Benedikt,

that question came to me while working on COMMONSRDF-2...

Personally I see Apache Commons as our current target for graduation. 
Therefore I'd prefer to use those coordinates already in incubation 
(that's considered a best practices to avoid issues on graduation). But 
of course anybody else could have other opinion.

In that case, how does Commons manages different artifacts per 
component? Because we currently have three (parent, api and simple imp). 
So my idea was to put all together under org.apache.commons.rdf groupId, 
but we can also stay at org.apache.commons and solve it at the 
artifacts' level.

Thanks for bringing here this discussion and your valuable feedback.

Cheers,


On 28/03/15 14:13, Benedikt Ritter wrote:
> Hi guys,
>
> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates for
> incubation releases of Commons RDF. I may have missed something, but my
> last information was, that Commons RDF has not yet decided whether it
> want's to join Apache Commons or go TLP in the end. So the situation looks
> like the following to me:
>
> As long as Commons RDF has not decided to join Apache Commons in the end,
> Commons RDF should not use the Apache Commons groupid. So maven coordinates
> should be:
>
> <groupid>org.apache.commonsrdf</groupid>
> <artifactid>commons-rdf</artifactid>
>
> If Commons RDF has already decided not to go TLP and to join Apache Commons
> after incubation, the coordinates should be (have i missed that decision?
> Sorry!):
>
> <groupid>org.apache.commons</groupid>
> <artifactid>commons-rdf</artifactid>
>
> Regards,
> Benedikt
>
> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
>

-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [COMMONSRDF] GroupID for incubation releases

Posted by Gary Gregory <ga...@gmail.com>.
Note your that you'll need one Maven module, POM, and groupid per jar you
release. At least that's how I would do it. It sounds like you are dealing
with a Maven multi-module project. Commons has at least one of those:
Commons JCS.

Gary

On Sat, Mar 28, 2015 at 6:13 AM, Benedikt Ritter <br...@apache.org> wrote:

> Hi guys,
>
> there is a discussion in COMMONSRDF-2 [1] about the maven coordinates for
> incubation releases of Commons RDF. I may have missed something, but my
> last information was, that Commons RDF has not yet decided whether it
> want's to join Apache Commons or go TLP in the end. So the situation looks
> like the following to me:
>
> As long as Commons RDF has not decided to join Apache Commons in the end,
> Commons RDF should not use the Apache Commons groupid. So maven coordinates
> should be:
>
> <groupid>org.apache.commonsrdf</groupid>
> <artifactid>commons-rdf</artifactid>
>
> If Commons RDF has already decided not to go TLP and to join Apache Commons
> after incubation, the coordinates should be (have i missed that decision?
> Sorry!):
>
> <groupid>org.apache.commons</groupid>
> <artifactid>commons-rdf</artifactid>
>
> Regards,
> Benedikt
>
> [1] https://issues.apache.org/jira/browse/COMMONSRDF-2
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory