I think Claude introduced the idea of LTS releases, so I'm curious about
whether he thinks that the audience for stability includes people who would use
a "stable" series of the kind Osma describes, even without the Apache
imprimatur.
ajs6f
> On Jan 24, 2017, at 2:57 PM, Andy Seaborne
I've had some experience with protocols such as are described by Osma and I
think that they have real value for (particularly for large) users and sites.
And as he says, they can be automated. I would be willing to help with that. I
would like to learn more about Apache infrastructure.
That
>
> When a class is loaded, the is not run. That happens on first use.
>
Ah, this is what I did not understand correctly. Okay, no problem.
IMHO JenaSystem.init is a step in the right direction and better way than
> the current way initialization is done.
>
No argument here.
What would be
can then be used directly. The
>
>
>
>
>
>
>
> On 10 September 2015 at 22:50, Stian Soiland-Reyes <st...@apache.org> wrote:
>> On 10 September 2015 at 18:13, aj...@virginia.edu <aj...@virginia.edu> wrote:
>>> If this is a matter o
If this is a matter of "just a couple of lines in the manifest file" cannot a
patch be created to do that in Jena itself? Are there inter-module dependency
issues that make that difficult?
---
A. Soroka
The University of Virginia Library
On Sep 10, 2015, at 11:49 AM, Reto Gmür
Is it your impression that the "special OSGi spice" additions are something
that Jena could reasonably adopt into normal builds? Then maybe they wouldn't
feel the need to do this…
---
A. Soroka
The University of Virginia Library
On Sep 9, 2015, at 4:06 PM, Andy Seaborne
I apologize if I am being thick here, but I don't understand how one goes about
checking the potential match without some kind of covering resource against
which to do that, something with a full representation of the graph. Can you
elaborate on how to check the validity of the match?
Thank
ads - that's the way the
>> world is going.
>>
>> So each quad is reduced to a
>>> single bloom filter comprising 4 items (15-bytes).
>>>
>>
>>Andy
>>
>> [*] even in memory, it might be worth allocating internal ids and work
an in-memory and a relational DB based version recently, but it was
just a quick POC.
Claude
On Wed, Aug 26, 2015 at 3:27 PM, A. Soroka aj...@virginia.edu wrote:
Hey, folks--
There hasn't been too much feedback on my proposal for a journaling
DatasetGraph:
https://github.com/ajs6f/jena
On Aug 28, 2015, at 6:17 AM, Andy Seaborne a...@apache.org wrote:
On 27/08/15 16:53, aj...@virginia.edu wrote:
Andy-- Thanks, these comments are really helpful! I've replied
in-line in a few places to clarify or answer questions, or ask some
of my own. {grin}
--- A. Soroka The University
a...@apache.org wrote:
On 28/08/15 12:22, aj...@virginia.edu wrote:
In fact, this is why I tried (for a first try) a design with only one
transaction committing at a time, which amounts to SW in terms of
serializability, I thought.
No :-(
But I am allowing multiple writers to
assemble changes
Andy-- Thanks, these comments are really helpful! I've replied in-line in a few
places to clarify or answer questions, or ask some of my own. {grin}
---
A. Soroka
The University of Virginia Library
On Aug 27, 2015, at 5:35 AM, Andy Seaborne a...@apache.org wrote:
1) All-transactional action:
). There's scope to add forms on top.
void execSelect(Query query, ConsumerQuerySolution action)
is one possibility.
Andy
On 04/08/15 16:14, aj...@virginia.edu wrote:
Is this a little bit like Sesame 4's new Repository helper type? Not totally
the same thing, but similar
On Aug 4, 2015, at 4:32 PM, Andy Seaborne a...@apache.org wrote:
On 03/08/15 17:13, aj...@virginia.edu wrote:
I've made some emendations to (hopefully) fix this problem. In order to so
do, I added a method to Lock itself to report the quality of an instance,
simply as an enumeration. I had hoped
in several places (search for empty graphs in the SPARQL 1.1 update spec)
and various SPARQL Updates behaviours may differ depending on whether the
storage layer records the presence of empty graphs or not
Rob
On 05/08/2015 13:44, aj...@virginia.edu aj...@virginia.edu wrote:
Just
Is this a little bit like Sesame 4's new Repository helper type? Not totally
the same thing, but similar in that it's bringing a lot of convenience together
around the notion of dataset?
http://rdf4j.org/doc/4/programming.docbook?view#Stream_based_querying_and_transaction_handling
---
A.
is a ReentrantReadWriteLock + counting
support to catch application errors).
DatasetGraphWithRecord is relying on single-W for its own datastructures.
Andy
On 29/07/15 21:22, aj...@virginia.edu wrote:
I'm not sure I understand this advice-- are you saying that because no
DatasetGraph can be assumed
).
DatasetGraphWithRecord is relying on single-W for its own datastructures.
Andy
On 29/07/15 21:22, aj...@virginia.edu wrote:
I'm not sure I understand this advice-- are you saying that because no
DatasetGraph can be assumed to support MR, there isn't any point in trying
to support MR
, in practice, all DatasetGraphs _do_ support MR,
there's no need to enforce it at the level of DatasetGraphWithRecord?
---
A. Soroka
The University of Virginia Library
On Jul 29, 2015, at 4:14 PM, Andy Seaborne a...@apache.org wrote:
On 27/07/15 18:06, aj...@virginia.edu wrote:
Is there some
Thanks for the feedback, Andy! See comment in-line below.
---
A. Soroka
The University of Virginia Library
On Jul 25, 2015, at 7:43 AM, Andy Seaborne a...@apache.org wrote:
A first look - there's quite a lot to do with the release at the moment.
Right, I don't expect anyone to get around to
extending Quad.
---
A. Soroka
The University of Virginia Library
On Jul 25, 2015, at 7:43 AM, Andy Seaborne a...@apache.org wrote:
On 23/07/15 14:18, aj...@virginia.edu wrote:
After a longish conversation with Andy Seaborne, I've worked up a simple
journaling DatasetGraph wrapping implementation
Since I'm trying to get to an understanding from which I can write a PR with
some new Javadocs for these type, let me try out the following:
Iter should never be used for a return type or parameter type in the public
contract of a class. It is only to be used inside implementation code and it
After a longish conversation with Andy Seaborne, I've worked up a simple
journaling DatasetGraph wrapping implementation. The idea is to use journaling
to support proper aborting behavior (which I believe this code does) and to add
to that a semantic for DatasetGraph::addGraph that copies
Okay, so if I were writing some new code in a Jena module, and I needed to do
some of the tasks for which these guys have facilities (e.g. filtering), how
should I select a type to use? Should I only use ExtendedIterator's methods if
the thing I already have in hand is an ExtendedIterator? Put
On Jun 29, 2015, at 9:33 AM, Claude Warren cla...@xenei.com wrote:
If there were an ETag per dataset and a method on the dataset to force an
ETag reset would this address the index issue in that the indexer could reset
the ETag when it deemed appropriate?
It might-- for that indexer. I would
(); // to retrieve the current tag.
Claude
On Mon, Jun 29, 2015 at 2:50 PM, aj...@virginia.edu aj...@virginia.edu
wrote:
On Jun 29, 2015, at 9:33 AM, Claude Warren cla...@xenei.com wrote:
If there were an ETag per dataset and a method on the dataset to force
an ETag reset would
Good point. (Speaking as someone who regularly has to be corrected about this
{grin}.)
---
A. Soroka
The University of Virginia Library
On Jun 29, 2015, at 12:57 PM, Andy Seaborne a...@apache.org wrote:
Good comments - I've made some revisions to the page based on this input.
It reminded
Right, I updated my comment right after I made it, when I noticed the
difference.
I shouldn't think it matters which one to keep. LazyIterator is a little
shorter to write. :)
There are a number of other Iterators (noted in the comments to that ticket)
that seem to be depreciate-able. E.g.
The Stream API is definitely significantly different from the Function API.
Maybe you mean that Stream is significantly different from Iterator (which is
surely is)?
Everything you say about deprecation seems very fair to me, and that's what
happened to a number of other types (e.g. in
How about using a Java 8 SupplierIteratorT? That's pretty lazy.
---
A. Soroka
The University of Virginia Library
On Jun 17, 2015, at 5:07 AM, Claude Warren cla...@xenei.com wrote:
I wanted to use it in an application. Is there a replacement?
On Wed, Jun 17, 2015 at 9:10 AM, Andy Seaborne
that be the _only_ think
rdfcat does in Jena 3.
---
A. Soroka
The University of Virginia Library
On Jun 10, 2015, at 6:39 AM, Andy Seaborne a...@apache.org wrote:
On 09/06/15 17:11, aj...@virginia.edu wrote:
I don't see any actual references in the documentation to rdfcat. Perhaps it
can
a...@apache.org wrote:
On 09/06/15 16:26, aj...@virginia.edu wrote:
Okay, now I get why we're sticking with shading in Guava, at least
for now (since this seems like the kind of problem that OSGi solves
and hopefully Jigsaw will solve).
Are there objections to ejecting shaded Guava from
Is there some high level overview of Lizard/Mantis/TDB2 yet extant? Like the
kind of thing we might see at a conference?
In any event, thanks for working on this-- it's great to know that Jena will be
able to cluster soon.
---
A. Soroka
The University of Virginia Library
On Jun 8, 2015, at
-guava does not mention com.google.guava:guava. Elephas picks up
the Hadoop dependency.
Andy
On 08/06/15 14:26, aj...@virginia.edu wrote:
I think the idea of breaking the shaded Guava artifact out of the
main cycle is great. It's clearly not a subject of work under most
On Jun 8, 2015, at 6:35 PM, Andy Seaborne a...@apache.org wrote:
less - there is no transactionality across the contained graphs. (Model.graph
transactions aren't connected to dataset transactions)
Ah, glad I asked! {grin}
As far as model-as-views-of-datasets: is it true that all that is
I don't see any actual references in the documentation to rdfcat. Perhaps it
can be deprecated?
---
A. Soroka
The University of Virginia Library
On Jun 8, 2015, at 11:24 AM, Andy Seaborne a...@apache.org wrote:
People use rdfcat :-( but nowadays riot is better IMO (scale, speed,
arguments,
So to be clear, part of the idea here is to boost the visibility of
transactions, and one of the things that wants doing as part of that is to
provide for copy-on-add-graph semantics for the in-memory dataset so that
transactionality is coherent across such a dataset. Right now it instead is a
central, which should only change
when we upgrade Guava, in which case it could be re-enabled in the SNAPSHOT
build or vote+released as a separate artifact (which might be slightly odd
as it contains no Jena contributions beyond the package name)
On 4 Jun 2015 14:33, aj...@virginia.edu aj
In examining and discussing https://issues.apache.org/jira/browse/JENA-959, it
seems to me (a Jena newbie!) that Jena's CLI action is built up in jena-core,
in package jena.cmdline.
If that is correct, and Jena has its own CLI code, wouldn't it be better to
replace this with a modern CLI
, Andy Seaborne a...@apache.org wrote:
On 08/06/15 15:47, aj...@virginia.edu wrote:
In examining and discussing
https://issues.apache.org/jira/browse/JENA-959, it seems to me (a
Jena newbie!) that Jena's CLI action is built up in jena-core, in
package jena.cmdline.
If that is correct, and Jena
I have had this problem since I began tinkering. The only solution I have found
is make sure that the jena-shaded-guava project is never open when any project
that refers to types therein is open. This isn't much of a burden, and I
suppose it has something to do with the Maven magic that is
Wearing my Jena user's hat for a moment, this would be lovely and I would be
happy to help with it.
A project [1] on which I work persists RDF via some very complex mappings into
and out of a JCR repository, and being able to stream it a little more
gracefully would be a nice win for us. Those
and
the web site if we decided to use 120 or any other number. We can probably
leave some basic policies (no tabs, no unused imports, etc).
WDYT?
Bruno
From: A. Soroka aj...@virginia.edu
To: dev@jena.apache.org dev@jena.apache.org
Sent: Wednesday, May 13, 2015 2:07 AM
Subject
, May 8, 2015 at 3:54 AM, aj...@virginia.edu aj...@virginia.edu
wrote:
I'm building a PR [1] right now as a sort of think-piece to give us
something concrete to look at. I'm building it up out of ONLY things that
Eclipse/javac can determine are definitely impossible to execute or
redundant
...@virginia.edu aj...@virginia.edu
wrote:
I'm building a PR [1] right now as a sort of think-piece to give us
something concrete to look at. I'm building it up out of ONLY things that
Eclipse/javac can determine are definitely impossible to execute or
redundant or never used, including:
- Private
code. Also any commented code as
well. We have a source control system, one can always look into the
history to get that stuff. Using a field just makes it worse IMO... it'll
never get removed if we do that.
-Stephen
On Thu, May 7, 2015 at 11:26 AM, A. Soroka aj...@virginia.edu wrote
Okay, that makes sense, although in some ways it seems more like a rationale
for keeping _an_ interface, rather than a rationale that Jena should have its
_own_ interface. But keeping Guava types from leaking through makes sense.
I will send a PR sometime soon with some Java 8 work in those
. I you
want I can send you the source to test your implementation with. This will
mean adding junit-contracts as a dependency for your tests.
Claude
On Fri, May 1, 2015 at 5:26 PM, aj...@virginia.edu aj...@virginia.edu
wrote:
Yes, in that case, the change was no more than extends
free to submit an issue
to https://issues.apache.org/jira/browse/FUNCTOR or ping the commons dev
mailing list :-)
All the bestBruno
From: aj...@virginia.edu aj...@virginia.edu
To: dev@jena.apache.org
Sent: Saturday, May 2, 2015 6:05 AM
Subject: Java 8 Streams Was: What can
and Property types but you need to write code to create
these things to put them in all the slots and it starts to obscure the
simplicity of what is going on.
On Mon, May 4, 2015 at 11:50 AM, aj...@virginia.edu aj...@virginia.edu
wrote:
Thank you for the heads up: I was unaware of Commons
a RDFList
(or an iterator on one) is returned .
Claude
On Fri, May 1, 2015 at 5:12 PM, aj...@virginia.edu aj...@virginia.edu
wrote:
Oh, now I think I understand your point better.
Yes, I have already trawled that code and worked over those reusable guys,
and yes, you will certainly
.
Claude
On Fri, May 1, 2015 at 4:53 PM, aj...@virginia.edu aj...@virginia.edu
wrote:
As for the Filter implementation. will that be transparant to filter
implementations? I assume so.
I think this was in response to my question about Filter?
If you mean that things that currently
PM, aj...@virginia.edu aj...@virginia.edu
wrote:
Oh, now I think I understand your point better.
Yes, I have already trawled that code and worked over those reusable guys,
and yes, you will certainly still be able to combine and reuse Predicates
in the same way that you have used Filters
Great! Thank you.
Would Jena be similarly interested in trying to migrate
org.apache.jena.util.iterator.Filter to java.util.function.Predicate?
---
A. Soroka
The University of Virginia Library
On May 1, 2015, at 3:32 AM, Andy Seaborne a...@apache.org wrote:
On 30/04/15 17:11, aj
I'm a long-time user of Jena, but entirely new to its internals, so this may be
a very off-the-mark opinion, but perhaps org.apache.jena.util.iterator.Map1
could be swapped out for java.util.function.Function?
---
A. Soroka
The University of Virginia Library
On Apr 30, 2015, at 10:39 AM, Andy
55 matches
Mail list logo