Re: Why we need Fuseki

I'd be happy to supply the current code we have, just need to get the current project delivered (classic spec delivered after the code due date!) Will tidy and do a pull request if anyone is interested..? We also check the file type and possibly transform before the load. But this is a simple map

Re: Why we need Fuseki

On 04/04/17 19:02, Dick Murray wrote: Slightly lateral on the topic but we use a Thrift endpoint compiled against Jena to allow multiple languages to use Jena. Think interface supporting sparql, sparul and bulk load... I'd like to put in binary versions of the protocols behind a

Re: DOAP

Some (I think most) projects maintain their own DOAP, and it can be found in a different location of a project website per-project. --- A. Soroka The University of Virginia Library > On Apr 4, 2017, at 1:43 PM, Laura Morales wrote: > >>

Re: Why we need Fuseki

i am sure to run an official Fuseki-'Reference' public endpoint is a very harmless and for everyone comprehensible suggestion... Open source, at Apache at least, is about community. The code is available and anyone can put use it to put up a server. That is how the costs get shared. There is

Re: Jena + HDT

Well, I'm not that familiar with HDT, thus, I'm probably wrong. And I saw right now that they also provide some kind of indexing concept. Let's wait for response from Andy and/or Rob. (In the meantime, I'll play around with HDT and Jena today to get some more insights. ) >> Jena HDT is

Re: DOAP

> Some (I think most) projects maintain their own DOAP, and it can be found > in a different location of a project website per-project. Is there a way to download all of them automatically? I'd like to load a graph of free projects on my Fuseki, but I'm struggling to find any archive of DOAP

Re: Jena 3 - Printing ^^xsd:string in output

You can also force RDF 1.0 Mode as follows: JenaRuntime.isRDF11 = false; We use this at my employer where other components in our ecosystem are not yet RDF 1.1 aware Rob On 03/04/2017 22:43, "Andy Seaborne" wrote: On 03/04/17 21:22, Nikolaos Beredimas wrote:

Re: Jena + HDT

Hi, I have some experience using HDT with Jena. I think HDT is an amazing technology and I've so far been happy with the performance, but as Rob said, the use case matters a lot and benchmarking is recommended. In my case I have a conversion pipeline [1] that converts a set of MARC

Re: Why we need Fuseki

you can either let them access it with sparql and, for example, the fuseki client (but other clients can do as well) or you can write a program in any language you like and use one of the HTTP clients in this language to send a prefabricated query to the endpoint. i do this even to load the data,

Re: Why we need Fuseki

Oh sorry. Well, I asked this question to Javed - I know why I'd need Fuseki such that I can query/update the RDF dataset by using SPARQL via the HTTP protocol. I only wanted to show him how much more things he need from his local Jena application to an remote SPARQL endpoint. But thank you anyway

Re: Why we need Fuseki

On Mon, 03 Apr 2017 14:54:53 +0200, javed khan wrote: Hi Why we need fuseki server in semantic web applications. We can run SPARQL queries without it, like we do using Jena syntax. If Fuseki would have had (like Virtuoso) a reference public endpoint with a well

Re: Jena + HDT

HDT is primarily on disk. Whether it is query-able depends on the exact encoding, there is one encoding designed primarily for transportation of data and another designed for querying called HDT-FoQ aka focused on querying In either case, there will be some memory usage as they do perform some

Re: Jena 3 - Printing ^^xsd:string in output

Good to know that. Good thing it isn't final then! Andy On 04/04/17 10:18, Rob Vesse wrote: You can also force RDF 1.0 Mode as follows: JenaRuntime.isRDF11 = false; We use this at my employer where other components in our ecosystem are not yet RDF 1.1 aware Rob On 03/04/2017 22:43,

Re: Jena + HDT

04.04.2017, 13:10, Dave Reynolds kirjoitti: Not to detract from HDT in anyway but we routinely load 25M triple file sets (Turtle) to TDB in around 10mins on modest cloud VMs and rather faster on local desktops with modern SSDs. So HDT might still have some load speed benefits but at that scale

Re: Jena + HDT

From what I know of HDT, it supports one access pattern very well (linked data fragments), and it is good for published large datasets on the web. If there is enough memory to store some of the access structures it would be OK for SPARQL. Without all indexes., as the RAM/disk ratio gets worse

Re: DOAP

https://jena.apache.org/about_jena/jena.rdf On 03/04/17 19:47, Laura Morales wrote: Does Apache still provide DOAP files for its projects? https://projects.apache.org/doap.html

Re: Jena + HDT

Hi, I made an apples-to-apples comparison using my bibliographic data set. The starting point is a NT file with 30M triples (unfortunately not yet available to the public), gzipped into a 400MB file (uncompressed it would be 4GB). I used my i3-2330M laptop with 8GB RAM and SSD. Converting

Re: Jena + HDT

Not to detract from HDT in anyway but we routinely load 25M triple file sets (Turtle) to TDB in around 10mins on modest cloud VMs and rather faster on local desktops with modern SSDs. So HDT might still have some load speed benefits but at that scale it is less than 2x and not hours v.s.

Re: Why we need Fuseki

>> If Fuseki would have had (like Virtuoso) a reference public endpoint with a >> well known database, then were no need for such a question... This sounds like an interesting idea. Do you have some time to devote to it? What database are you thinking of serving? --- A. Soroka The University

Re: Why we need Fuseki

This sounds like an interesting idea. Do you have some time to devote to it? What database are you thinking of serving? Well, we can take the same as Virtuoso, Dbpedia-dataset, THE BEST would be EXACTLY the same as Virtuoso to make comparisons, but this is an old 'idea' of mine, here in

Re: Why we need Fuseki

Well, there is semantic_forms, it's kind of a Virtuoso on top of Jena TDB, but contrary to dbPedia instance of Virtuoso, one can load what (s)he wants. It's also kind of a Fuseki, with compliant SPARQL, plus generated forms and web framework. Sandbox: semantic-forms.cc:9111/ Project;

Re: Why we need Fuseki

I've got nothing against DBPedia, although I don't think it's particularly useful to make a comparison in that way between Virtuoso and Jena, unless you are ready to do the work to ensure that the actual resourcing for the two services is the same, forever. Where would you be serving this

Re: Why we need Fuseki

I've got nothing against DBPedia, although I don't think it's particularly useful to make a comparison in that way between Virtuoso and Jena, unless you are ready to do the work to ensure that the actual resourcing for the two services is the same, forever. what kind of problems do you

Re: Why we need Fuseki

On Apr 4, 2017, at 10:03 AM, baran...@gmail.com wrote: > >> I've got nothing against DBPedia, although I don't think it's particularly >> useful to make a comparison in that way between Virtuoso and Jena, unless >> you are ready to do the work to ensure that the actual resourcing for the >>

Re: Why we need Fuseki

what kind of problems do you see, i have a local Fuseki server running downloaded nt-Dbpedia datasets, which i regulary actualize. That doesn't really help anyone compare Jena and Virtuoso, does it? :) Ofcourse it does, if you run those datasets as a public Fuseki-endpoint like

Re: Why we need Fuseki

> On Apr 4, 2017, at 10:25 AM, baran...@gmail.com wrote: > >>> what kind of problems do you see, i have a local Fuseki server running >>> downloaded nt-Dbpedia datasets, which i regulary actualize. >> That doesn't really help anyone compare Jena and Virtuoso, does it? :) > Ofcourse it does, if

Re: Why we need Fuseki

On Tue, 04 Apr 2017 16:40:00 +0200, A. Soroka wrote: On Apr 4, 2017, at 10:25 AM, baran...@gmail.com wrote: what kind of problems do you see, i have a local Fuseki server running downloaded nt-Dbpedia datasets, which i regulary actualize. That doesn't really help anyone

Re: Why we need Fuseki

What about sparql.org? That is a reference public Fuseki endpoint hosted by Apache on behalf of the projects, sure it is a toy dataset but it is a public endpoint The projects team role is to organise the development of the software which we make it available freely to the public under the

Re: DOAP

Thanks for the link; it displays well in semantic_forms : http://semantic-forms.cc:9111/display?displayuri=http%3A%2F%2Fjena.apache.org but I think it would be better if the URI representing Jena the software would be within the DOAP document, like this:

Re: Why we need Fuseki

In practical terms hosting a public endpoint is an expensive business. To take DBPedia as an example it is billions of triples and so needs appropriate hardware. Let’s assume you wanted to host this in Amazon EC2 and wanted to use a r3.8xlarge instance (32 cores, 244 GiB RAM, 2x320GB

Re: DOAP

> https://jena.apache.org/about_jena/jena.rdf What I meant is DOAP files for all Apache projects, not only Jena.

Re: Why we need Fuseki

Slightly lateral on the topic but we use a Thrift endpoint compiled against Jena to allow multiple languages to use Jena. Think interface supporting sparql, sparul and bulk load... On 3 Apr 2017 6:36 pm, "Martynas Jusevičius" wrote: > By using uniform protocols such as