Hi Reto,

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:
Hi Andy,

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 
dataset. getUnionModel.

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 Fuseki).

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.



-----Original Message-----
From: Reto Gmür <r...@factsmission.com>
Sent: Friday, March 9, 2018 3:42 PM
To: users@jena.apache.org
Subject: RE: Getting Symmetric Concise Bounded Description with Fuseki

Great, it works!

Here's the code: https://github.com/linked-solutions/fuseki-scbd-describe


-----Original Message-----
From: Andy Seaborne <a...@apache.org>
Sent: Thursday, March 8, 2018 5:35 PM
To: users@jena.apache.org
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.

org.apache.jena.fuseki.cmd.FusekiCmd.main(args ...)



-----Original Message-----
From: ajs6f <aj...@apache.org>
Sent: Saturday, March 3, 2018 5:13 PM
To: users@jena.apache.org
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>

Hi all,

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
single query
and not to use any non-standard SPARQL feature.


Reply via email to