Closed GoogleCodeExporter closed 9 years ago
This is not reproducible with an empty registry. Note in the exception trace
that the error is actually thrown while trying to unregister the service.
Also, the server 138.119.12.49 is no longer responding to external requests (I
was able to connect to it once and successfully register the service, but no
longer).
That said, I've seen this problem before. It is possible to get data into
Virtuoso that you can't then extract with the Jena driver. Even if you used
the Jena driver to put the data in. In the past, I've seen this with
properties that weren't valid URIs. I suspect if you query the service
definition in your current registry (you'll have to use the Virtuoso SPARQL
endpoint, since the Jena interface is the thing throwing the error), you'll
find the problem. You can then use the SPARQL endpoint or the command-line
isql client to remove the offending statement(s), at which point you'll be able
to use the Jena driver again.
In short: not a SADI problem, but rather a bug in the Virtuoso Jena driver.
You could come up with a contained example (i.e.: use Jena to insert this data
into an empty graph, try to use Jena to query the same data, throw exception)
and submit it as a bug to Virtuoso.
Please reopen this if the above turns out not to be on point and you've got
more to add.
Original comment by elmccar...@gmail.com
on 26 Sep 2011 at 7:20
I had problems exporting the Virtuoso graph for the registry using Jena, which
fits with your explanation. I will switch back to a registry backed by a RDF
file. I was having problems with my sadi-registry emptying itself. I though
using virtuoso might help. I suspect it is a file locking issue, as it happens
when you try to view or add services to the registry, and SHARE is running.
It's really hard to reproduce this and submit a bug report though.
Original comment by matthew....@gmail.com
on 26 Sep 2011 at 7:26
Well, we are using a Virtuoso-backed registry for the main SADI registry and
it's been stable. The problems are only cause by service definitions/class
definitions that are actually invalid. Try this query to find problematic
statements:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX sadi: <http://sadiframework.org/ontologies/sadi.owl#>
SELECT DISTINCT ?service ?p
WHERE
{
?service rdf:type sadi:Service .
?service sadi:decoratesWith ?decoration .
?decoration owl:onProperty ?p .
?decoration owl:someValuesFrom ?valuesFrom .
FILTER (regex(str(?p), "[,< ]") || regex(str(?valuesFrom), "[,< ]"))
}
Once you've found them, deleting them is trivial if the SPARQL endpoint is
setup for SPARUL. Otherwise you'll have to do it from the isql client.
Original comment by elmccar...@gmail.com
on 26 Sep 2011 at 7:42
The services registered ok to the main repro. I guess the likely explanation
then is that the virtuoso driver is not playing ball with the older version of
virtuoso (Aug 2 2010). What version are you using there?
Original comment by matthew....@gmail.com
on 26 Sep 2011 at 7:51
It registered fine for me locally in Virtuoso 6. The version of Virtuoso on
sadiframework.org is 5.0.11.
It really looks like the ontology defining your service classes (or one that it
imports) changed between the time when you first registered your service and
the time that you re-registered it. The stack trace pasted in the original bug
report shows the service being unregistered, so there was already a definition
there. That definition will be the one that was problematic. And it should
still be in there, because it can't be removed by through the Jena interface.
Original comment by elmccar...@gmail.com
on 26 Sep 2011 at 7:55
Original issue reported on code.google.com by
matthew....@gmail.com
on 26 Sep 2011 at 6:57