Re: Why we need Fuseki
Hello everyone, sorry for resurrecting an old thread, but I've only discovered it now. I'd like to add to this discussion that I am running a public instance of Fuseki [1], even though it's only a small one. It's meant to host only free data, and hopefully be useful to other free software projects that wish to use such data for any purpose. It only serves data through the SPARQL endpoint in addition to a simple HTTP API offering some "prepared queries", it doesn't have a UI, and right now it only hosts small graphs (millions of triples). If there is anybody else interested in supporting a public instance of Fuseki, any help with this project would be greatly appreciated :) So far Fuseki has always worked seamlessly for me, therefore any help should be directed at finding more datasets, writing more "prepared queries" for the public API, or making other programs that take advantage of this service. Thank you all for your great work on Jena/Fuseki. Flavio [1] https://metadb.peers.community
Re: Why we need Fuseki
On Wed, 05 Apr 2017 09:52:18 +0200, Andrew U Frank wrote: what went wrong is the HUGE competition from google, financed by advertising. everybody has learned that search for information is free (except stock market and a few others). the investment in the "good idea" is large, because you will have to compete with google's 24/7 service. Of course! But perhaps, behind the scenes, with a lot of money, Google has also manipulated the development of a query language for Semantic Web into a 'cul-de-sack' where it cannot be a competitor for Google. Yes, this is only a conspiracy theory and i think it doesn't hurt that users know somebody have had 'SUCH' presumptions sometimes... baran -- Using Opera's mail client: http://www.opera.com/mail/
Re: Why we need Fuseki
what went wrong is the HUGE competition from google, financed by advertising. everybody has learned that search for information is free (except stock market and a few others). the investment in the "good idea" is large, because you will have to compete with google's 24/7 service. i run a sparql server reliably on a small hardware for a few users - it is very useful, runs easily and unless you have the "wide public" as users, with little effort. a very simplistic systemd automatic start... when you go for dbpedia as a service for everybody you are in a serious project, not a demonstration. i would not know how to make a business case for such a thing, therefore i do not see your manager asking for it either. - if it is for limited database for a limited community, the cost is likely much smaller than any comparable solution. andrew -- em.o.Univ.Prof. Dr. sc.techn. Dr. h.c. Andrew U. Frank +43 1 58801 12710 direct Geoinformation, TU Wien +43 1 58801 12700 office Gusshausstr. 27-29 +43 1 55801 12799 fax 1040 Wien Austria+43 676 419 25 72 mobil On 04/04/2017 06:30 PM, baran...@gmail.com wrote: > > >> 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 SSD, 10 GigE network) as an example. The hourly rate >> for this is $2.66 per hour which works out as approximately $23,000 >> per year, even if we were to use a reserve instance and pay up front >> that would still cost approximately $12,000 per year. This is before >> we even take into account bandwidth, Storage and ongoing support >> costs. As has already been pointed out everybody here is volunteers, >> we do not have any large corporate sponsors like other high profile >> Apache projects, so where do you expect that money to come from? >> >> Rob > > I know about the calculations since so many years, but 'out of the > blue' if some managers wanted a presentation with my Sparql-Query-UI > using the well-known Dbpedia public endpoint and they wanted to see > very fluently working query-process a bit more intelligent then > Google, and if you come then after 10 minutes with 'Excuse me, yo know > the costs of an endpoint...', they think, where a good idea is, there > is also money for it in such a simple demonstration case, why is there > no money for such a good idea? To make some simple live-experience > with a permanently reliable public-endpoint accessible for each one to > each time is much-much more important than harebrained SPARQL-queries. > > I have had always the feeling something went wrong in this story, the > question is what? > > baran > > * >
Re: Why we need Fuseki
On Tue, 04 Apr 2017 21:33:48 +0200, Andy Seaborne wrote: 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 no distinction of "official". People-capacity is the biggest limitation to everything for open source projects. The project has "sparql.org" (it's on Apache hardware - it's a little VM) which I set up - the management and allocation of project VMs is by the Apache infrastructure team who have it highly automated. They automate everything - economies of scale. Even keeping "sparql.org" up vaguely 24x7 isn't trivial. Most of the time, nothing needs doing. But there are short bursts of activity needed to fix things. Last week it went down - I was travelling - and I get twitter reports. Turns out that the VM is hosed in weird and wonder VM/memory ways and it needs Apache Infrastructure to reboot - that problem took time to track down. sparql.org gets all sorts of web-rubbish coming its way as well. That includes DOS attacks and people hitting it with repeated queries ... in parallel. It's a small VM -- we are lucky enough to get free. The Apache Software Foundation runs almost entirely on volunteer effort - there are a few (small single digits) employees keeping the core (email, archives, SVN, git) infrastructure up and running. The rest of the infrastructure is kept up and running by volunteers (e.g. the build server). It would be nice to put up a more interesting data set on sparql.org and to take time refresh its UI (it's the old Fuseki1) with a nice SPARQL query editor/form. Something small - 1-2 M triples to run in memory. And it needs people-time. Andy All this means in practice also: The most important app-case of Fuseki (running as a public endpoint) cannot be demonstrated by its developers in a real-world-scenario with a well-known database like dbpedia, because this costs too much and there is nobody to finance this. But small steps with sparql.org as Fuseki-public-endpoint are possible... Thanks for the clear and detailed report, how the situation at moment is... baran -- Using Opera's mail client: http://www.opera.com/mail/
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 no distinction of "official". People-capacity is the biggest limitation to everything for open source projects. The project has "sparql.org" (it's on Apache hardware - it's a little VM) which I set up - the management and allocation of project VMs is by the Apache infrastructure team who have it highly automated. They automate everything - economies of scale. Even keeping "sparql.org" up vaguely 24x7 isn't trivial. Most of the time, nothing needs doing. But there are short bursts of activity needed to fix things. Last week it went down - I was travelling - and I get twitter reports. Turns out that the VM is hosed in weird and wonder VM/memory ways and it needs Apache Infrastructure to reboot - that problem took time to track down. sparql.org gets all sorts of web-rubbish coming its way as well. That includes DOS attacks and people hitting it with repeated queries ... in parallel. It's a small VM -- we are lucky enough to get free. The Apache Software Foundation runs almost entirely on volunteer effort - there are a few (small single digits) employees keeping the core (email, archives, SVN, git) infrastructure up and running. The rest of the infrastructure is kept up and running by volunteers (e.g. the build server). It would be nice to put up a more interesting data set on sparql.org and to take time refresh its UI (it's the old Fuseki1) with a nice SPARQL query editor/form. Something small - 1-2 M triples to run in memory. And it needs people-time. Andy baran
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 lookup so shouldn't cause any issues. Our bulk load isn't RDF patch, it's a load of one or more data files into a new graph possibly with a transform performed at some point in the future, which you check by querying the load ID... Dick On 4 Apr 2017 8:15 pm, "Andy Seaborne" wrote: 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 RDFConnection. Bulk load would be RDF patch -- "bulk changes". Andy > On 3 Apr 2017 6:36 pm, "Martynas Jusevičius" > wrote: > > By using uniform protocols such as HTTP and SPARQL (over HTTP), you >> decouple server implementation from client implementation. >> >> You can execute SPARQL commands on Fuseki using PHP, C#, JavaScript or >> any other language. But that involves networking. >> >> You can only use the Jena API from Java (and then some JVM-compatible >> languages). >> >> On Mon, Apr 3, 2017 at 5:02 PM, javed khan wrote: >> >>> Thank you Lorenz, I have read that website but unfortunately did not get >>> the concept. Let me try to read it again. >>> >>> >>> >>> On Mon, Apr 3, 2017 at 4:35 PM, Lorenz Buehmann < >>> buehm...@informatik.uni-leipzig.de> wrote: >>> >>> Javed ... I'll simply cite the "slogan" from the web page [1] and recommend to read [2] "Fuseki: serving RDF data over HTTP" [1] https://jena.apache.org/documentation/serving_data/ [2] https://jena.apache.org/documentation/fuseki2/ On 03.04.2017 14:54, 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. > > >> >
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 RDFConnection. Bulk load would be RDF patch -- "bulk changes". Andy On 3 Apr 2017 6:36 pm, "Martynas Jusevičius" wrote: By using uniform protocols such as HTTP and SPARQL (over HTTP), you decouple server implementation from client implementation. You can execute SPARQL commands on Fuseki using PHP, C#, JavaScript or any other language. But that involves networking. You can only use the Jena API from Java (and then some JVM-compatible languages). On Mon, Apr 3, 2017 at 5:02 PM, javed khan wrote: Thank you Lorenz, I have read that website but unfortunately did not get the concept. Let me try to read it again. On Mon, Apr 3, 2017 at 4:35 PM, Lorenz Buehmann < buehm...@informatik.uni-leipzig.de> wrote: Javed ... I'll simply cite the "slogan" from the web page [1] and recommend to read [2] "Fuseki: serving RDF data over HTTP" [1] https://jena.apache.org/documentation/serving_data/ [2] https://jena.apache.org/documentation/fuseki2/ On 03.04.2017 14:54, 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.
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 HTTP and SPARQL (over HTTP), you > decouple server implementation from client implementation. > > You can execute SPARQL commands on Fuseki using PHP, C#, JavaScript or > any other language. But that involves networking. > > You can only use the Jena API from Java (and then some JVM-compatible > languages). > > On Mon, Apr 3, 2017 at 5:02 PM, javed khan wrote: > > Thank you Lorenz, I have read that website but unfortunately did not get > > the concept. Let me try to read it again. > > > > > > > > On Mon, Apr 3, 2017 at 4:35 PM, Lorenz Buehmann < > > buehm...@informatik.uni-leipzig.de> wrote: > > > >> Javed ... > >> > >> I'll simply cite the "slogan" from the web page [1] and recommend to > >> read [2] > >> > >> "Fuseki: serving RDF data over HTTP" > >> > >> > >> > >> [1] https://jena.apache.org/documentation/serving_data/ > >> > >> [2] https://jena.apache.org/documentation/fuseki2/ > >> > >> > >> On 03.04.2017 14:54, 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. > >> > > >> > >> >
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 SSD, 10 GigE network) as an example. The hourly rate for this is $2.66 per hour which works out as approximately $23,000 per year, even if we were to use a reserve instance and pay up front that would still cost approximately $12,000 per year. This is before we even take into account bandwidth, Storage and ongoing support costs. As has already been pointed out everybody here is volunteers, we do not have any large corporate sponsors like other high profile Apache projects, so where do you expect that money to come from? Rob I know about the calculations since so many years, but 'out of the blue' if some managers wanted a presentation with my Sparql-Query-UI using the well-known Dbpedia public endpoint and they wanted to see very fluently working query-process a bit more intelligent then Google, and if you come then after 10 minutes with 'Excuse me, yo know the costs of an endpoint...', they think, where a good idea is, there is also money for it in such a simple demonstration case, why is there no money for such a good idea? To make some simple live-experience with a permanently reliable public-endpoint accessible for each one to each time is much-much more important than harebrained SPARQL-queries. I have had always the feeling something went wrong in this story, the question is what? baran * -- Using Opera's mail client: http://www.opera.com/mail/
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 Apache foundations non-profit corporate charter. Our role is not to sell the software or to evangelise any particular vision of how the software should be used. This is very different to someone like OpenLink Software who are a commercial company and who have an interest in convincing end users to use their software in order to generate income and pay their and pay their bills. 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 SSD, 10 GigE network) as an example. The hourly rate for this is $2.66 per hour which works out as approximately $23,000 per year, even if we were to use a reserve instance and pay up front that would still cost approximately $12,000 per year. This is before we even take into account bandwidth, Storage and ongoing support costs. As has already been pointed out everybody here is volunteers, we do not have any large corporate sponsors like other high profile Apache projects, so where do you expect that money to come from? Rob On 04/04/2017 16:01, "baran...@gmail.com" wrote: 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 compare Jena and Virtuoso, does it? :) >> Ofcourse it does, if you run those datasets as a public Fuseki-endpoint >> like Virtuoso... > > At which point you have the same problem I named before. Unless the > resourcing for those public endpoints is the same, you don't have a real > comparison at all. Dbpedia-dataset is a relative small one, with a bit good-will cooperation i see there no prblems, otherwise you can forget the idea of Semantic Web, but you did it already, i think... > >>> I'm sorry, I am a bit confused; are you able to volunteer some time or >>> resources to this purpose? What you would like the Jena team to do to >>> help _you_ implement this idea? >> Jena Team should run A REFERENCE PUBLIC ENDPOINT and say to the world >> 'here we are', this is not my job, it has something to do with >> 'credibility' of the actual develepement... > > I don't know if this is always quite clear, so it sometime bears > remarking; the Jena team (like all Apache efforts) is an all-volunteer > group. No one is paid by Apache to work on Jena. If you would like to > take your idea forward, let's talk about how to do that. If you just > want someone else to implement it for you, it is not the job of anyone > on this list to do so, so we can end this conversation. Why not, ofcourse we can end it, if you see no other way, you say, make it yourself. But the USERS spended so many time in this environment and they have a right to say, what they think the right way is and i am sure to run an official Fuseki-'Reference' public endpoint is a very harmless and for everyone comprehensible suggestion... baran -- Using Opera's mail client: http://www.opera.com/mail/
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 compare Jena and Virtuoso, does it? :) Ofcourse it does, if you run those datasets as a public Fuseki-endpoint like Virtuoso... At which point you have the same problem I named before. Unless the resourcing for those public endpoints is the same, you don't have a real comparison at all. Dbpedia-dataset is a relative small one, with a bit good-will cooperation i see there no prblems, otherwise you can forget the idea of Semantic Web, but you did it already, i think... I'm sorry, I am a bit confused; are you able to volunteer some time or resources to this purpose? What you would like the Jena team to do to help _you_ implement this idea? Jena Team should run A REFERENCE PUBLIC ENDPOINT and say to the world 'here we are', this is not my job, it has something to do with 'credibility' of the actual develepement... I don't know if this is always quite clear, so it sometime bears remarking; the Jena team (like all Apache efforts) is an all-volunteer group. No one is paid by Apache to work on Jena. If you would like to take your idea forward, let's talk about how to do that. If you just want someone else to implement it for you, it is not the job of anyone on this list to do so, so we can end this conversation. Why not, ofcourse we can end it, if you see no other way, you say, make it yourself. But the USERS spended so many time in this environment and they have a right to say, what they think the right way is and i am sure to run an official Fuseki-'Reference' public endpoint is a very harmless and for everyone comprehensible suggestion... baran -- Using Opera's mail client: http://www.opera.com/mail/
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 you run those datasets as a public Fuseki-endpoint like > Virtuoso... At which point you have the same problem I named before. Unless the resourcing for those public endpoints is the same, you don't have a real comparison at all. >> I'm sorry, I am a bit confused; are you able to volunteer some time or >> resources to this purpose? What you would like the Jena team to do to help >> _you_ implement this idea? > Jena Team should run A REFERENCE PUBLIC ENDPOINT and say to the world 'here > we are', this is not my job, it has something to do with 'credibility' of the > actual develepement... I don't know if this is always quite clear, so it sometime bears remarking; the Jena team (like all Apache efforts) is an all-volunteer group. No one is paid by Apache to work on Jena. If you would like to take your idea forward, let's talk about how to do that. If you just want someone else to implement it for you, it is not the job of anyone on this list to do so, so we can end this conversation. --- A. Soroka The University of Virginia Library
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 Virtuoso... Where would you be serving this data from? Do you have perhaps employer backing or other long-term backing for this? Such a service should be A REFERENCE PUBLIC ENDPOINT run by Jena Develepoment like Virtuoso runs it with Dbpedia, but Jena Team can take another dataset ofcourse. Is there now such a A REFERENCE PUBLIC ENDPOINT running by Jena Team? If you think, this is not necessary, then ok... I'm sorry, I am a bit confused; are you able to volunteer some time or resources to this purpose? What you would like the Jena team to do to help _you_ implement this idea? Jena Team should run A REFERENCE PUBLIC ENDPOINT and say to the world 'here we are', this is not my job, it has something to do with 'credibility' of the actual develepement... baran --- A. Soroka The University of Virginia Library -- Using Opera's mail client: http://www.opera.com/mail/
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 >> two services is the same, forever. > > 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? :) >> Where would you be serving this data from? Do you have perhaps employer >> backing or other long-term backing for this? > > Such a service should be A REFERENCE PUBLIC ENDPOINT run by Jena Develepoment > like Virtuoso runs it with Dbpedia, but Jena Team can take another dataset > ofcourse. Is there now such a A REFERENCE PUBLIC ENDPOINT running by Jena > Team? If you think, this is not necessary, then ok... I'm sorry, I am a bit confused; are you able to volunteer some time or resources to this purpose? What you would like the Jena team to do to help _you_ implement this idea? --- A. Soroka The University of Virginia Library
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 see, i have a local Fuseki server running downloaded nt-Dbpedia datasets, which i regulary actualize. Where would you be serving this data from? Do you have perhaps employer backing or other long-term backing for this? Such a service should be A REFERENCE PUBLIC ENDPOINT run by Jena Develepoment like Virtuoso runs it with Dbpedia, but Jena Team can take another dataset ofcourse. Is there now such a A REFERENCE PUBLIC ENDPOINT running by Jena Team? If you think, this is not necessary, then ok... baran --- A. Soroka The University of Virginia Library On Apr 4, 2017, at 9:34 AM, baran...@gmail.com wrote: 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 this listing about 5-6 years old, i think... thanks, baran --- A. Soroka The University of Virginia Library On Apr 4, 2017, at 4:48 AM, baran...@gmail.com wrote: 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 known database, then were no need for such a question... baran -- Using Opera's mail client: http://www.opera.com/mail/ -- Using Opera's mail client: http://www.opera.com/mail/ -- Using Opera's mail client: http://www.opera.com/mail/
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 data from? Do you have perhaps employer backing or other long-term backing for this? --- A. Soroka The University of Virginia Library > On Apr 4, 2017, at 9:34 AM, baran...@gmail.com wrote: > > >> 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 this listing about 5-6 years old, i think... > > thanks, baran > >> >> --- >> A. Soroka >> The University of Virginia Library >> >>> On Apr 4, 2017, at 4:48 AM, baran...@gmail.com wrote: >>> >>> 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 known database, then were no need for such a question... >>> >>> baran >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >> > > > -- > Using Opera's mail client: http://www.opera.com/mail/
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; https://github.com/jmvanel/semantic_forms/wiki New release soon. 2017-04-04 15:34 GMT+02:00 : > > 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 this listing about 5-6 years old, i think... > > thanks, baran > > > >> --- >> A. Soroka >> The University of Virginia Library >> >> On Apr 4, 2017, at 4:48 AM, baran...@gmail.com wrote: >>> >>> 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 known database, then were no need for such a question... >>> >>> baran >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >>> >> >> > > -- > Using Opera's mail client: http://www.opera.com/mail/ > -- Jean-Marc Vanel http://www.semantic-forms.cc:9111/display?displayuri=http:/ /jmvanel.free.fr/jmv.rdf%23me Déductions SARL - Consulting, services, training, Rule-based programming, Semantic Web +33 (0)6 89 16 29 52 <+33%206%2089%2016%2029%2052> Twitter: @jmvanel , @jmvanel_fr ; chat: irc://irc.freenode.net#eulergui
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 this listing about 5-6 years old, i think... thanks, baran --- A. Soroka The University of Virginia Library On Apr 4, 2017, at 4:48 AM, baran...@gmail.com wrote: 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 known database, then were no need for such a question... baran -- Using Opera's mail client: http://www.opera.com/mail/ -- Using Opera's mail client: http://www.opera.com/mail/
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 of Virginia Library > On Apr 4, 2017, at 4:48 AM, baran...@gmail.com wrote: > > 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 known database, then were no need for such a question... > > baran > > -- > Using Opera's mail client: http://www.opera.com/mail/
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 known database, then were no need for such a question... baran -- Using Opera's mail client: http://www.opera.com/mail/
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 and sorry for confusion!
Cheers,
Lorenz
> 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, because i like the sparql 1.1 update standard more
> than the more or less idosyncratic API. the query says then something
> like
>
> "INSERT DATA { GRAPH " < graphname >
> " {" < triples> "} }"
>
> it is - at least for small applications (<1 G triples) and slow code to
> produce the triples, fast enough.
>
> andrew
>
--
Lorenz Bühmann
AKSW group, University of Leipzig
Group: http://aksw.org - semantic web research center
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, because i like the sparql 1.1 update standard more
than the more or less idosyncratic API. the query says then something
like
"INSERT DATA { GRAPH " < graphname >
" {" < triples> "} }"
it is - at least for small applications (<1 G triples) and slow code to
produce the triples, fast enough.
andrew
--
em.o.Univ.Prof. Dr. sc.techn. Dr. h.c. Andrew U. Frank
+43 1 58801 12710 direct
Geoinformation, TU Wien +43 1 58801 12700 office
Gusshausstr. 27-29 +43 1 55801 12799 fax
1040 Wien Austria+43 676 419 25 72 mobil
On 04/04/2017 07:41 AM, Lorenz B. wrote:
> Then let me ask you a question:
>
> Ok, so you said you have Jena and maybe loaded some data. How would you
> allow users on the web to access this data? How would you implement this?
>
>> Thank you Lorenz, I have read that website but unfortunately did not get
>> the concept. Let me try to read it again.
>>
>>
>>
>> On Mon, Apr 3, 2017 at 4:35 PM, Lorenz Buehmann <
>> buehm...@informatik.uni-leipzig.de> wrote:
>>
>>> Javed ...
>>>
>>> I'll simply cite the "slogan" from the web page [1] and recommend to
>>> read [2]
>>>
>>> "Fuseki: serving RDF data over HTTP"
>>>
>>>
>>>
>>> [1] https://jena.apache.org/documentation/serving_data/
>>>
>>> [2] https://jena.apache.org/documentation/fuseki2/
>>>
>>>
>>> On 03.04.2017 14:54, 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.
Re: Why we need Fuseki
Then let me ask you a question: Ok, so you said you have Jena and maybe loaded some data. How would you allow users on the web to access this data? How would you implement this? > Thank you Lorenz, I have read that website but unfortunately did not get > the concept. Let me try to read it again. > > > > On Mon, Apr 3, 2017 at 4:35 PM, Lorenz Buehmann < > buehm...@informatik.uni-leipzig.de> wrote: > >> Javed ... >> >> I'll simply cite the "slogan" from the web page [1] and recommend to >> read [2] >> >> "Fuseki: serving RDF data over HTTP" >> >> >> >> [1] https://jena.apache.org/documentation/serving_data/ >> >> [2] https://jena.apache.org/documentation/fuseki2/ >> >> >> On 03.04.2017 14:54, 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. >>> >> -- Lorenz Bühmann AKSW group, University of Leipzig Group: http://aksw.org - semantic web research center
Re: Why we need Fuseki
It also means that you can load a triple store (eg TDB) with some RDF using jena command line tools (tdbloader, tdbloader2), deploy a fuseki instance that connects to the triple store, then use a sparql client (e.g. http://sparqlclient.eionet.europa.eu/) to execute SPARQL against the data without writing a single line of java/php/ruby/php/c#, etc code. On 4/3/17, 1:36 PM, "Martynas Jusevičius" wrote: By using uniform protocols such as HTTP and SPARQL (over HTTP), you decouple server implementation from client implementation. You can execute SPARQL commands on Fuseki using PHP, C#, JavaScript or any other language. But that involves networking. You can only use the Jena API from Java (and then some JVM-compatible languages). On Mon, Apr 3, 2017 at 5:02 PM, javed khan wrote: > Thank you Lorenz, I have read that website but unfortunately did not get > the concept. Let me try to read it again. > > > > On Mon, Apr 3, 2017 at 4:35 PM, Lorenz Buehmann < > buehm...@informatik.uni-leipzig.de> wrote: > >> Javed ... >> >> I'll simply cite the "slogan" from the web page [1] and recommend to >> read [2] >> >> "Fuseki: serving RDF data over HTTP" >> >> >> >> [1] https://jena.apache.org/documentation/serving_data/ >> >> [2] https://jena.apache.org/documentation/fuseki2/ >> >> >> On 03.04.2017 14:54, 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. >> > >> >>
Re: Why we need Fuseki
By using uniform protocols such as HTTP and SPARQL (over HTTP), you decouple server implementation from client implementation. You can execute SPARQL commands on Fuseki using PHP, C#, JavaScript or any other language. But that involves networking. You can only use the Jena API from Java (and then some JVM-compatible languages). On Mon, Apr 3, 2017 at 5:02 PM, javed khan wrote: > Thank you Lorenz, I have read that website but unfortunately did not get > the concept. Let me try to read it again. > > > > On Mon, Apr 3, 2017 at 4:35 PM, Lorenz Buehmann < > buehm...@informatik.uni-leipzig.de> wrote: > >> Javed ... >> >> I'll simply cite the "slogan" from the web page [1] and recommend to >> read [2] >> >> "Fuseki: serving RDF data over HTTP" >> >> >> >> [1] https://jena.apache.org/documentation/serving_data/ >> >> [2] https://jena.apache.org/documentation/fuseki2/ >> >> >> On 03.04.2017 14:54, 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. >> > >> >>
Re: Why we need Fuseki
i like fuseki because it follows closely the standard sparql 1.1 to allow update over https, which makes my programs more portable (to other sparql servers which follow 1.1 - few so far). fuseiki can easily be run as a service on a host, ready for clients to use it... -- em.o.Univ.Prof. Dr. sc.techn. Dr. h.c. Andrew U. Frank +43 1 58801 12710 direct Geoinformation, TU Wien +43 1 58801 12700 office Gusshausstr. 27-29 +43 1 55801 12799 fax 1040 Wien Austria+43 676 419 25 72 mobil On 04/03/2017 02:54 PM, 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. >
Re: Why we need Fuseki
Thank you Lorenz, I have read that website but unfortunately did not get the concept. Let me try to read it again. On Mon, Apr 3, 2017 at 4:35 PM, Lorenz Buehmann < buehm...@informatik.uni-leipzig.de> wrote: > Javed ... > > I'll simply cite the "slogan" from the web page [1] and recommend to > read [2] > > "Fuseki: serving RDF data over HTTP" > > > > [1] https://jena.apache.org/documentation/serving_data/ > > [2] https://jena.apache.org/documentation/fuseki2/ > > > On 03.04.2017 14:54, 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. > > > >
Re: Why we need Fuseki
Is this a question or a statement? Dick Original message From: javed khan Date: 03/04/2017 13:54 (GMT+00:00) To: users@jena.apache.org Subject: Why we need Fuseki Hi Why we need fuseki server in semantic web applications. We can run SPARQL queries without it, like we do using Jena syntax.
Re: Why we need Fuseki
Javed ... I'll simply cite the "slogan" from the web page [1] and recommend to read [2] "Fuseki: serving RDF data over HTTP" [1] https://jena.apache.org/documentation/serving_data/ [2] https://jena.apache.org/documentation/fuseki2/ On 03.04.2017 14:54, 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. >
