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. I am going to try publishing LARQ artifacts on the Apache staging repository, so I can check everything is fine. Since LARQ, at the moment, depends on TDB (for testing) LARQ release must follow TDB release. (I am planning to remove that dependency, since it adds little value and it creates this sort of troubles). I'll try this tomorrow. >> It's just a small extension for ARQ, therefore it does not need a full >> .zip distribution. Or, that is necessary anyway? > > ARQ does not have a distribution zip. Ack. Same will be for LARQ. >> Probably, just the >> -source-release.zip is necessary as per jena-iri, for example. >> Do you agree? > > The source-release is absolutely required. It *is* the release. > Everything else is additional in Apache process. Ack. >> 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? 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: Index: pom.xml =================================================================== --- pom.xml (revision 1203107) +++ pom.xml (working copy) @@ -53,6 +53,7 @@ <ver.jena>2.6.5-incubating-SNAPSHOT</ver.jena> <ver.arq>2.8.9-incubating-SNAPSHOT</ver.arq> <ver.tdb>0.9.0-incubating-SNAPSHOT</ver.tdb> + <ver.larq>1.0.0-incubating-SNAPSHOT</ver.larq> <!-- These two go together --> <ver.jetty>7.2.1.v20101111</ver.jetty> @@ -75,6 +76,12 @@ <dependency> <groupId>org.apache.jena</groupId> + <artifactId>jena-larq</artifactId> + <version>${ver.larq}</version> + </dependency> + + <dependency> + <groupId>org.apache.jena</groupId> <artifactId>jena-arq</artifactId> <version>${ver.arq}</version> <classifier>tests</classifier> We also had people asking for LARQ (and Fuseki) on the mailing list since we moved to Apache. 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. 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) 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. 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 >> >
