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.)
> 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.
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.
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.
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?
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 .
}
