On Sun, Jan 22, 2012 at 3:13 PM, Andy Seaborne <[email protected]> wrote: > What do statics ARQ.VERSION and ARQ.BUILD_DATE contain? They are strings > with the version burnt into the binary. > > The stacktrace is an old version of ARQ but I can't tell which. (The > website says they have tested from Jena 2.5.5 but at 2.6 Jena went from Java > 1.4 to Java 1.5 and generics.)
So, you're going to love this. I'm running com.hp.hpl.jena:arq:jar:basis-temp-2.8.8:compile -- 2.8.8 plus a bug fix I integrated locally. I've been too cowardly to upgrade to the latest version of Jena until there was a corresponding TDB. Should I just go ahead with that? One way or the other, well ahead of their last test. > > >> Instead, ARQ is just normalizing a+ to (a)+. Is the Jena<->store model >> predicated on the program writing SPARQL compatible with the target >> store's SPARQL? > > (a)+ is legal SPARQL syntax. Of course. > > It looks like internally they convert the query object back to a string to > pass to Virtuoso. That's why you don't get a warning nor does the engine > backoff to a strategy that works on for any storage. The whole execution is > taken by Virtuoso. So, you've answered my question. They could call the Path API in this case. It might be worth my trouble to fork their code and fix it. > > IIRC they don't support any path syntax. > > Trickery: > > Create an ARQ dataset and put the Virtuoso default graph. ARQ will access > Virtuoso programmatically via the graph API. If OpenLink have implemented a > StageGenerator, then basic patterns should be sent to the database so get > some optimization. Otherwise, if there is no helper route, ARQ slugs it out > by brute force and ignorance. No idea of performance - it will depend on > the query as to how the work is divided. Methinks I need to read some of their code. > > Andy > > > On 22/01/12 19:41, Benson Margulies wrote: >> >> On Sun, Jan 22, 2012 at 2:28 PM, Robert Vesse<[email protected]> wrote: >>> >>> Hi Benson >>> >>> What version of Virtuoso is this? >> >> >> It's the latest and greatest. 06.01.3127 and the included Jena driver. > > > That's not the latest. > > Virtuoso 6.1.4 is the open source one and commercial one is ahead of that. > 7? It is 6.1.4. It just prints 6.1.3127 when you start the server. > > >> Here's my ignorance on display: I'm passing Syntax.syntaxARQ. I would >> expect that, somewhere between ARQ and the virt-jena module, something >> would react to a property path by either (a) throwing an exception, or >> (b) automatically mapping it to something that works. After all, the >> PathParser class exists, why can't I ask ARQ to use it for me? >> >> Instead, ARQ is just normalizing a+ to (a)+. Is the Jena<->store model >> predicated on the program writing SPARQL compatible with the target >> store's SPARQL? >> >> One of my colleagues has had his head turned by benchmarks that say >> wonderful things about Virtuoso, and so I'm trying to find a >> relatively painless way to make Virtuoso and TDB swappable in the code >> we have, which has various 'modern' SPARQL queries lying about. >> >> >>> >>> OpenLink have been quite slow to move from their proprietary SPARQL >>> extensions to standardized SPARQL 1.1 syntax. They never supported any >>> property path syntax in the past and have been somewhat reluctant to proceed >>> too fast with implementing new SPARQL 1.1 features arguing that they don't >>> want to give 'standard' features to users that they then have to later >>> remove/alter (which is ironic given their quantity of proprietary >>> extensions) >>> >>> Have you tried checking with OpenLink about which versions (if any) >>> support property paths? Their mailing list for the open source version is >>> [email protected] >> >> >> I have pestered their forum, which does not have a good home for Jena >> questions. >> >> If there's something a driver can do to provoke ARQ into automatically >> doing the moral equivalent of: >> >> Path path = PathParser.parse("rdf:type/rdfs:subPropertyOf+", >> PrefixMapping.Standard); >> String uri = "urn:com.basistech:subprop"; >> PathLib.install(uri, path); >> >> I'd cheerfully fork their driver and do the work. >> >> >>> >>> Rob >>> >>> On Jan 22, 2012, at 10:10 AM, Benson Margulies wrote: >>> >>>> I was asked to do an experiment with Virtuoso. It looks to me as if >>>> ARQ mapped + to (), and then Virtuoso, consistent with its rather old >>>> SPARQL dialect, rejected (). Is there any way to tell ARQ what's what? >>>> Or is this ipso-facto a bug in the Virtuoso Jena driver. >>>> >>>> 2012-01-22 12:58:30,042 >>>> com.basistech.jdd.DocumentDatabaseClientFactory - JDD ping >>>> successful: http://localhost:4460/documentDatabase >>>> Exception in thread "main" com.hp.hpl.jena.shared.JenaException: Can >>>> not create QueryIterator.:virtuoso.jdbc4.VirtuosoException: SQ074: >>>> Line 12: SP030: SPARQL compiler, line 10: syntax error at '(' before >>>> 'rdfs:subPropertyOf' >>>> at virtuoso.jena.driver.VirtuosoQueryEngine.eval(Unknown Source) >>>> at >>>> com.hp.hpl.jena.sparql.engine.QueryEngineBase.evaluate(QueryEngineBase.java:138) >>>> at >>>> com.hp.hpl.jena.sparql.engine.QueryEngineBase.createPlan(QueryEngineBase.java:109) >>>> at >>>> com.hp.hpl.jena.sparql.engine.QueryEngineBase.getPlan(QueryEngineBase.java:97) >>>> at >>>> virtuoso.jena.driver.VirtuosoQueryEngine$VirtQueryEngineFactory.create(Unknown >>>> Source) >>>> at >>>> com.hp.hpl.jena.sparql.engine.QueryExecutionBase.getPlan(QueryExecutionBase.java:266) >>>> at >>>> com.hp.hpl.jena.sparql.engine.QueryExecutionBase.startQueryIterator(QueryExecutionBase.java:243) >>>> at >>>> com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execResultSet(QueryExecutionBase.java:248) >>>> at >>>> com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execSelect(QueryExecutionBase.java:94) >>>> >>>> >>>> >>>> PREFIX rex:<http://jug.basistech.com/2011/01/rex-entity#> >>>> PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#> >>>> >>>> # retrieve the URI for each defined relationship >>>> SELECT DISTINCT ?r >>>> WHERE { >>>> ?r rdfs:subPropertyOf+ rex:relationship . >>>> } >>> >>> >
