Hi Andy Andy Seaborne wrote: > On 02/02/12 08:34, Paolo Castagna wrote: >> Hi Andy >> >> Andy Seaborne wrote: >>>> Do you have a plan for LARQ? >>> >>> No plan whatsoever. I am at the limit of the number of things I can >>> manage. I was hoping you would deal with LARQ. >> >> Ack. I know you are busy. > > It is not about me being busy. I should not be the only do doing releases. > > Getting the first release of Fuseki out, Apache licensed, is important > as it establishes the codebase as clean. > > Referring to snapshots and the version confusion has not been helping on > jena-users@ > >>>> In relation to Fuseki, JENA-63 is still open/pending: >>>> https://issues.apache.org/jira/browse/JENA-63 >>>> But, if Fuseki is released first... LARQ cannot be included in it >>>> and JENA-63 can only be closed with the next Fuseki release. >>> >>> Do you want the release of Fuseki held up? > > I have staged TDB and pulled the Fuseki release but that's because there > is an issue with the zip build of Fuseki.
Ack. > Talis want TDB released surely? I let Talis answer that. ;-) As individual, I often use TDB/Fuseki as well as LARQ and I want to help with the release process. > >> Well, my colleagues who have used Fuseki to manage/explore their >> data on their machines, found free-text "searching" very useful >> (and I needed to tell them to always patch Fuseki to add LARQ to it). >> >> Patch is currently tiny and just a dependency on the Fuseki's pom.xml: > > Arguments based on "colleagues" don't work for me. > > If Talis/Kasabi is managing to usefully use it for their business then > great but it's all a black box to me, except for support time when you > direct people to jena-users@. > > It is a few lines of maven for LARQ to depend on Fuseki and build it's > own extended jar. > > This unlinks the release dependency. > > It allows LARQ to release to a different cycle to Fuseki. We can't > release Fuseki just for bug and enhancements in LARQ. > > I hope that updateable indexes happen - but making Fuseki have to > release for such a new feature seems a bad way to do it. So, one way forward is: - we close JENA-63 as "Won't Fix" or "Not a Problem" - we park JENA-164 until there is clear demand for it - people who want to have Fuseki with LARQ included can package it themselves No dependency links between Fuseki and LARQ from a release point of view. Shall I do that? I still want to have LARQ released, do it myself and/or help doing that. > See also JENA-190. > > .. patch to Fuseki POM only .. > >> We also had people asking for LARQ (and Fuseki) on the mailing list >> since we moved to Apache. > > We have more people asking about protocol and Fuseki. Getting a Apache > Fuseki out is important to me. Agree. >> >> The best scenario for me would be: >> >> 1. TDB is released first >> 2. LARQ and Fuseki are released soon after (with JENA-63 fixed/closed) >> >>> LARQ does not work SPARQL Update or with SPARQL Graph Store protocol. >> >> Yes, we discussed about this already. >> >> This is a known (and important) limitation. There is an open issue on >> this: https://issues.apache.org/jira/browse/JENA-164 >> It isn't a blocker to me my mind. > > JENA-164 blocks JENA-63 (your entry in JIRA on 11/Nov/11). > >> I'll document the known limitation. >> >> Re: JENA-164, you know the "update" route into Fuseki much better than >> I do, if you could just add a small comment (i.e. one or two paragraphs) > > The JIRA points to an email thread from Oct 2011 that deals with the > bulkloader problem. > > And I've suggested LARQ could create a DatasetGraph and catch every > add(quad)/delete(quad). > > A LARQ assember could simply name the dataset description it wraps. > Assemble the LARQ assember assembles the inner dataset. Fuseki service > points to LARQ. > > Seems quite practical to try to me. I'll try that. > But I'm not going to do it. Sure. >> on how this could be done... without big changes on the >> event/notification >> system, I'll do it. I have time tomorrow and probably next week. >> The problem I have with JENA-164 is that I do not see how I can >> "intercept" >> changes without changing Fuseki code. >> >>> We see on jena-users@ that people are using Fuseki via the update >>> protocols. >> >> Yep. >> >> All the people I saw using Fuseki (and LARQ) at work they were loading >> stuff with tdbloader(2) and then "exploring" the data (i.e. a read-only >> scenario). >> >> RDF publishing systems are often used in a mostly read >> scenarios, with little/few updates. In this case, rebuilding the Lucene >> index nightly would be a reasonable workaround, until JENA-164 is fixed. >> >>> Could LARQ be released separately as a bolt-on to Fuseki, with >>> instructions on how to build and maintain the index? I presume you want >>> to say its for read-only publishing at the moment. >> >> Yeah. >> >> I am not sure what you exactly mean "as a bolt-on to Fuseki". >> >> My colleagues love the fact that Fuseki is just a single jar file (with >> all the dependencies). LARQ is an extension which can simply added to >> the classpath (together with Lucene) (i.e. two jars). >> >> People wanting to use LARQ with Fuseki will need to repackage Fuseki >> if they want the single jar file with LARQ in it. >> >> A similar scenario will arise for GeoSPARQL (i.e. another cool SPARQL >> extension I/we would love to see/have and use in Fuseki). >> I can see how this can become a problem. > > Well, there is no activity on GeoSPARQL so the whole issue there is moot > for this release cycle. Sure. Paolo > > Andy > >> On the other hand, Fuseki is so easy to checkout/build/package that >> even if LARQ isn't included in it... people can package it themselves >> or third parties could distribute a pre-packaged version with all the >> cool extensions in it (not my preferred options for various reasons). >> >>> I'll hold things up for a day while we discuss this. >> >> Thanks. >> >> Paolo >> >>> >>> Andy >>> >>>> >>>> Paolo >>>> >>>>> >>>>> Andy >>>> >>> >
