You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Steinar Bang <sb...@dod.no> on 2016/03/28 13:45:54 UTC
Should I replace Jena Fuseki 1.1 with 1.3.1 or 2.3.1?
Hi,
I have an installation that is currently using (as near as I can tell)
Jena Fuseki 1.1, which is a bit out of date.
Going forward, should I would it be best to replace it with Jena Fuseki
1.3.1 or with Jena Fuseki 2.3.1?
By best, I'm thinking of
- performance?
- In particular SPARQL query perfomance
- compatibility?
- REST endpoint compatibility? (that may be determined by the SPARQL
protocol...?)
- Directory layout compatibility? (I know this is different)
- TDB compatibility
Thanks!
- Steinar
Re: Should I replace Jena Fuseki 1.1 with 1.3.1 or 2.3.1?
Posted by Don Rolph <do...@gmail.com>.
2.3.1 has the following advantages which we have leveraged:
- it cleanly supports persistent databases
- it has a real security module
On Mon, Mar 28, 2016 at 7:45 AM, Steinar Bang <sb...@dod.no> wrote:
> Hi,
>
> I have an installation that is currently using (as near as I can tell)
> Jena Fuseki 1.1, which is a bit out of date.
>
> Going forward, should I would it be best to replace it with Jena Fuseki
> 1.3.1 or with Jena Fuseki 2.3.1?
>
> By best, I'm thinking of
> - performance?
> - In particular SPARQL query perfomance
> - compatibility?
> - REST endpoint compatibility? (that may be determined by the SPARQL
> protocol...?)
> - Directory layout compatibility? (I know this is different)
> - TDB compatibility
>
> Thanks!
>
>
> - Steinar
>
--
73,
AB1PH
Don Rolph
Re: Should I replace Jena Fuseki 1.1 with 1.3.1 or 2.3.1?
Posted by Andy Seaborne <an...@apache.org>.
On 07/04/16 10:05, Steinar Bang wrote:
>>>>>> Andy Seaborne <an...@public.gmane.org>:
>
>> Hopefully, Fuseki2 is compatible with Fuseki1 configurations - it's
>> supposed to be anyway.
>
>> At some point (no plans), Fuseki1 is end-of-life. Currently, it's
>> only getting maintenance.
>
>> Fuseki2 runs as a service much better.
>
> Ok, thanks! Compared with what you said inline, Fuseki2 it is!
>
> One point I forgot to mention was that we want SPARQL query results as
> JSON-LD and that's possibly Fuseki2 only...? (If so, this definitely
> means going for Fuseki2).
Fuseki1 should support JSON-LD - they both use the same parser/write
code and fuseki1 is being rebuilt with each Jena release.
>
> One minor comment/question below:
>
>>> - Directory layout compatibility? (I know this is different)
>
>> It does have it's own "run" area. That's part of being more
>> OS-service oriented.
>
> As far as I can tell from the existing code,
Your code? Running Fuseki from within a program?
(That does work in Fuseki2 - jut call main - although a proper embedding
setup would be nicer - but IIRC Fuseki1 was no different)
> it operates with a TDB
> directory with the dataset embedded, while Fuseki2 seems to use the
> structure
> run/databases/<dataset-name>
>
> Ie. one separate TDB database per dataset...?
>
> Or is it just that the existing code creates a single dataset and names
> the directory it resides in "TDB" rather than using the dataset name...?
> (The existing code that wraps Fuseki1 _does_ seem to ensure that the
> a single dataset is always present and creates it if it isn't)
>
run/databases/ is where Fuseki2 puts TDB databases created via the UI.
A service configuration can point to anywhere on disk.
The command line way to start Fuseki2 is generally compatible with
Fuseki1 to aid migration. Running Fuseki2 as a OS-service is much easier.
Andy
Re: Should I replace Jena Fuseki 1.1 with 1.3.1 or 2.3.1?
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Andy Seaborne <an...@public.gmane.org>:
> Hopefully, Fuseki2 is compatible with Fuseki1 configurations - it's
> supposed to be anyway.
> At some point (no plans), Fuseki1 is end-of-life. Currently, it's
> only getting maintenance.
> Fuseki2 runs as a service much better.
Ok, thanks! Compared with what you said inline, Fuseki2 it is!
One point I forgot to mention was that we want SPARQL query results as
JSON-LD and that's possibly Fuseki2 only...? (If so, this definitely
means going for Fuseki2).
One minor comment/question below:
>> - Directory layout compatibility? (I know this is different)
> It does have it's own "run" area. That's part of being more
> OS-service oriented.
As far as I can tell from the existing code, it operates with a TDB
directory with the dataset embedded, while Fuseki2 seems to use the
structure
run/databases/<dataset-name>
Ie. one separate TDB database per dataset...?
Or is it just that the existing code creates a single dataset and names
the directory it resides in "TDB" rather than using the dataset name...?
(The existing code that wraps Fuseki1 _does_ seem to ensure that the
a single dataset is always present and creates it if it isn't)
Re: Should I replace Jena Fuseki 1.1 with 1.3.1 or 2.3.1?
Posted by Andy Seaborne <an...@apache.org>.
Hopefully, Fuseki2 is compatible with Fuseki1 configurations - it's
supposed to be anyway.
At some point (no plans), Fuseki1 is end-of-life. Currently, it's only
getting maintenance.
Fuseki2 runs as a service much better.
And as a WAR file.
On 28/03/16 12:45, Steinar Bang wrote:
> Hi,
>
> I have an installation that is currently using (as near as I can tell)
> Jena Fuseki 1.1, which is a bit out of date.
>
> Going forward, should I would it be best to replace it with Jena Fuseki
> 1.3.1 or with Jena Fuseki 2.3.1?
>
> By best, I'm thinking of
> - performance?
> - In particular SPARQL query perfomance
Makes no difference - same query engine.
> - compatibility?
There are better ways to configure Fuseki2 but --conf and the other
command line arguments work.
> - REST endpoint compatibility? (that may be determined by the SPARQL
> protocol...?)
Fuseki2 is better at a bit better at compliance than Fuseki1 (more
complete) and supports normal REST operations on the dataset itself.
For query/update Fuseki2 is compatible with Fuseki1.
> - Directory layout compatibility? (I know this is different)
It does have it's own "run" area. That's part of being more OS-service
oriented.
> - TDB compatibility
Same TDB.
>
> Thanks!
>
>
> - Steinar
>
Andy