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
On Thu, Apr 16, 2015 at 7:41 AM, Sergio Fernández wrote:
> Hi,
>
> On Wed, Apr 15, 2015 at 12:30 PM, Reto Gmür wrote:
>
> > On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández
> > wrote:
> >
> > > On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell
> > > wrote:
> > > >
> > > > BlankNodes cannot be com
Hi,
On Wed, Apr 15, 2015 at 12:30 PM, Reto Gmür wrote:
> On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández
> wrote:
>
> > On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell
> > wrote:
> > >
> > > BlankNodes cannot be compared across different SPARQL queries. That is
> > > a well known RDF issue, no
On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández wrote:
> On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell
> 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
On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell
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
On 14 April 2015 at 01:16, Reto Gmür wrote:
> On Sat, Apr 11, 2015 at 12:39 PM, Peter Ansell
> wrote:
>
>> On 11 April 2015 at 22:11, Reto Gmür wrote:
>> > On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter
>> wrote:
>> >
>> >> Hello Reto,
>> >>
>> >> 2015-03-30 14:45 GMT+02:00 Reto Gmür :
>> >>
On Sat, Apr 11, 2015 at 12:39 PM, Peter Ansell
wrote:
> On 11 April 2015 at 22:11, Reto Gmür wrote:
> > On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter
> wrote:
> >
> >> Hello Reto,
> >>
> >> 2015-03-30 14:45 GMT+02:00 Reto Gmür :
> >>
> >> > Hi all,
> >> >
> >> > The clerezza commons RDF prop
On 11 April 2015 at 22:11, Reto Gmür wrote:
> On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter wrote:
>
>> Hello Reto,
>>
>> 2015-03-30 14:45 GMT+02:00 Reto Gmür :
>>
>> > Hi all,
>> >
>> > The clerezza commons RDF proposal that was in the sandbox and is now in
>> the
>> > clerezza-rdf-core repos
On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter wrote:
> Hello Reto,
>
> 2015-03-30 14:45 GMT+02:00 Reto Gmür :
>
> > 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.com
On 30 March 2015 at 23:45, Reto Gmür 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 t
Hello Reto,
2015-03-30 14:45 GMT+02:00 Reto Gmür :
> 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 res
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 unf
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 wrote:
> On 28/03/15 17:40, Benedikt Ritter wrote:
>>
>> So for Commons RDF I would recommend the following:
>>
>> parent:
>>org.apache.commons:commons-r
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
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" wrote:
> On Sat, Mar 28, 2015 at 9:40 AM, Benedikt Rit
On Sat, Mar 28, 2015 at 9:40 AM, Benedikt Ritter wrote:
> 2015-03-28 16:37 GMT+01:00 Sergio Fernández :
>
> > 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 us
2015-03-28 16:37 GMT+01:00 Sergio Fernández :
> 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 pra
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 wrote:
>
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 an
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 look
20 matches
Mail list logo
