The whole DescribeHandler system is very(, very) old and hasn't changed
in ages, other than maintenance.
On 10/03/18 11:44, Reto Gmür wrote:
It first didn't quite work as I wanted it to: the model of the resource passed to the
describe model is the default graph so I got only the triples in that graph. Setting
"tdb:unionDefaultGraph true" didn't change the graph the DescribeHandler gets.
tdb:unionDefaultGraph only affects SPARQL execution.
Looking at the default implementation I saw that the Dataset can be accessed
from the context passed to the start method with
cxt.get(ARQConstants.sysCurrentDataset). I am now using the Model returned by
That should work. Generally available getUnionModel post-dates the
describe handler code.
I'm wondering why the DescribeBNodeClosure doesn't do the same but instead
queries for all graphs that contain the resource and then works on each of the
NamedModel individually. Is the UnionModel returned by the dataset inefficient
that you've chosen this approach?
I don't think so - much the same work is done, just in different places.
getUnionModel will work with blank node named graphs.
getUnionModel will do describes spanning graphs, iterating over named
graphs will not.
Also the code seems to assume that the name of the graph is a URI, does Jena not support
Blank Nodes as names for graphs (having an "anonymous node" as name might be
surprising but foreseen in RDF datasets)?
Again, old code (pre RDF 1.1, which is where bNode graph names came in).
Properly, nowadays, it should all work on DatasetGraph whose API does
work with bNode graphs. Again, history.
If you want to clean up, please do so.
It seems that even when a DescribeHandler is provided, the default handler is
executed as well. Is there a way to disable this?
IIRC all the handers are executed - the idea being to apply all policies
and handlers may only be able to describe certain classes. Remove any
not required, or set your own registry in the query (a bit tricky in
Another question is about the concept of "BNode closure", what's the rationale
for expanding only forward properties? Shouldn't a closure be everything that defines the
It is a simple, basic policy - the idea being that more appropriate ones
which are data-sensitive would be used. This basic one can go wrong
(FOAF graphs when people are bnodes) and does not handle IFP; it does
cover blank nodes used for values with structure and for RDF lists.
The point about DESCRIBE is that the "right" answer is not a fixed
data-independent algorithm but is best for the data being published.
From: Reto Gmür <r...@factsmission.com>
Sent: Friday, March 9, 2018 3:42 PM
Subject: RE: Getting Symmetric Concise Bounded Description with Fuseki
Great, it works!
Here's the code: https://github.com/linked-solutions/fuseki-scbd-describe
From: Andy Seaborne <a...@apache.org>
Sent: Thursday, March 8, 2018 5:35 PM
Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki
On 08/03/18 16:12, Reto Gmür wrote:
Thanks for the link ajs6f.
The described method for registering with the
works if Fuseki is embedded. Is there a way to add a
DescribeHandlerFactory to a stand-alone fuseki instance? ServiceLoaders
come to mind.
ServiceLoaders, or use ja:loadClass.
If there isn't such a possibility, what's the best way to embed
fuseki with the
full webapp (Fuseki UI and Admin functions)?
You just need to include it, set environment variables FUSEKI_HOME and
FUSEKI_BASE, put the files in the right place on disc
and call the main function.
From: ajs6f <aj...@apache.org>
Sent: Saturday, March 3, 2018 5:13 PM
Subject: Re: Getting Symmetric Concise Bounded Description with
You can replace Jena's DESCRIBE behavior with whatever you like:
On Mar 3, 2018, at 8:03 AM, Reto Gmür <r...@factsmission.com>
I've noticed that a DESCRIBE query returns the Concise Bounded
(CBD) of a resource, i.e. it expands forward properties to the next
non-blank node. Is it possible to configure FUSEKI to also follow
properties backwards when answering a DESCRIBE query? Or is there
another query that would return that? By using the non-standard
possibility to query for blank-nodes I could get the full resource
context with multiple queries but I would refer to do this with a
and not to use any non-standard SPARQL feature.