RE: Getting Symmetric Concise Bounded Description with Fuseki

[Reto Gmür]

> -Original Message-
> From: Martynas Jusevičius <marty...@atomgraph.com>
> Sent: Monday, March 12, 2018 5:11 PM
> To: jena-users-ml <users@jena.apache.org>
> Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki
> 
> I disagree about SCBD as the default. In a Linked Data context, DESCRIBE is
> usually used to return description of a resource, meaning the resource is in 
> the
> subject position. And then bnode closure is added, because otherwise there
> would be no way to reach those bnodes. It's not about exploring the graph in
> all directions.

That a property describes more the subject than the object is not something 
intrinsic to RDF semantics but a design choice in ontologies. 

In https://www.w3.org/DesignIssues/LinkedData.html Tim Beners-Lee emphasizes 
that the description returned when dereferencing a resource must be a full 
Minimum Self Contained Graph (aka SCBD) for a graph to be browsable. In my 
opinion it should be possible to build linked data applications for browsable 
graphs that access the backend only via SPARQL and ideally only with a single 
query per returned representation. With Fuseki this is possible with a custom 
handler, GraphDB returns SCBD by default, with Virtuoso and other stores this 
is a matter of  configuration, with Stardog this is not possible. None of this 
implementations violates the SPARQL specification, in my opinion it's a shame 
that SPARQL doesn't provide a standard method for returning SCBD, but that's 
another story.

Cheers,
Reto

> 
> If you want more specific description, then you can always use CONSTRUCT.
> 
> Some triplestores, for example Dydra, allow specification of the description
> algorithm using a special PREFIX scheme, such as
> 
> PREFIX describeForm: 
> 
> On Mon, Mar 12, 2018 at 4:40 PM, Reto Gmür <r...@factsmission.com>
> wrote:
> 
> > Hi Andy
> >
> > > -Original Message-
> > > From: Andy Seaborne <a...@apache.org>
> > > Sent: Saturday, March 10, 2018 3:47 PM
> > > To: users@jena.apache.org
> > > Subject: Re: Getting Symmetric Concise Bounded Description with
> > > Fuseki
> > >
> > > 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
> >

Re: Getting Symmetric Concise Bounded Description with Fuseki

[Martynas Jusevičius]

I disagree about SCBD as the default. In a Linked Data context, DESCRIBE is
usually used to return description of a resource, meaning the resource is
in the subject position. And then bnode closure is added, because otherwise
there would be no way to reach those bnodes. It's not about exploring the
graph in all directions.

If you want more specific description, then you can always use CONSTRUCT.

Some triplestores, for example Dydra, allow specification of the
description algorithm using a special PREFIX scheme, such as

PREFIX describeForm: 

On Mon, Mar 12, 2018 at 4:40 PM, Reto Gmür <r...@factsmission.com> wrote:

> Hi Andy
>
> > -Original Message-
> > From: Andy Seaborne <a...@apache.org>
> > Sent: Saturday, March 10, 2018 3:47 PM
> > To: users@jena.apache.org
> > Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki
> >
> > 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 node?
> >
> > 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.
>
> I realize that. My question was more about the definition of "closure".
> Following forward properties might be a pragmatic approach, the data can
> often be modelled in such a way that this default implementation of
> DESCRIBE returns very useful results.
>
> But, in some cases even forward properties only, might result in a too
> comprehensive response. So if the current system doesn't allow disabling
> the default handler one cannot make this answer smaller (e.g. return a
> description of instances of ex:Organization without all its ex:hasMember
> properties). I think fuseki should both allow returning re

Re: Getting Symmetric Concise Bounded Description with Fuseki

[Andy Seaborne]

On 12/03/18 15:40, Reto Gmür wrote:

Hi Andy


-Original Message-
From: Andy Seaborne <a...@apache.org>
Sent: Saturday, March 10, 2018 3:47 PM
To: users@jena.apache.org
Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki

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 node?

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.


I realize that. My question was more about the definition of "closure". 
Following forward properties might be a pragmatic approach, the data can often be 
modelled in such a way that this default implementation of DESCRIBE returns very useful 
results.

But, in some cases even forward properties only, might result in a too 
comprehensive response. So if the current system doesn't allow disabling the 
default handler


DescribeHandlerRegistry.get().clear();


one cannot make this answer smaller (e.g. return a description of instances of 
ex:Organization without all its ex:hasMember properties). I think fuseki should 
both allow returning results that contain more as well as less than the default.

As for the best default I think SCBD is the best because independently of the 
data being published and ontologies being used it returns everything the server 
knows about a particular resource, only stopping the contextual description 
where the client can get more information with another DESCRIBE query. With 
SCBD a connected graph can be fully explored with DESCRIBE starting at any 
resource. Yes the response might be to comprehensive and so there needs to be a 
mechanism for DESCRIBE handlers to allow responses that are smaller than the 
default. But I argue that wasting a bit of bandwith in some cases is a better 
default than arbitrarily limiting information and thus providing too little 
information in many cases.

Reto




  Andy



Cheers,
Reto


-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

Cheers,
Reto


-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

RE: Getting Symmetric Concise Bounded Description with Fuseki

[Reto Gmür]

Hi Andy

> -Original Message-
> From: Andy Seaborne <a...@apache.org>
> Sent: Saturday, March 10, 2018 3:47 PM
> To: users@jena.apache.org
> Subject: Re: Getting Symmetric Concise Bounded Description with Fuseki
> 
> 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 node?
> 
> 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.

I realize that. My question was more about the definition of "closure". 
Following forward properties might be a pragmatic approach, the data can often 
be modelled in such a way that this default implementation of DESCRIBE returns 
very useful results.

But, in some cases even forward properties only, might result in a too 
comprehensive response. So if the current system doesn't allow disabling the 
default handler one cannot make this answer smaller (e.g. return a description 
of instances of ex:Organization without all its ex:hasMember properties). I 
think fuseki should both allow returning results that contain more as well as 
less than the default.

As for the best default I think SCBD is the best because independently of the 
data being published and ontologies being used it returns everything the server 
knows about a particular resource, only stopping the contextual description 
where the client can get more information with another DESCRIBE query. With 
SCBD a connected graph can be fully explored with DESCRIBE starting at any 
resource. Yes the response might be to comprehensive and so there needs to be a 
mechanism for DESCRIBE handlers to allow responses that are smaller than the 
default. But I argue that wasting a bit of bandwith in some cases is a better 
default than arbitrarily limiting information and thus providing too little 
information in many cases.

Reto


> 
>  Andy
> 
> >
> > Cheers,
> > Reto
> >
> >> -Original Message-
> >> From: Reto Gmür <r...@factsmission.com>
> >> Sent: Friday, March 9, 2018 3:42 PM
> >> To: users@jena.apache

Re: Getting Symmetric Concise Bounded Description with Fuseki

[Andy Seaborne]

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 
node?


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.


Andy



Cheers,
Reto


-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

Cheers,
Reto


-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
DescribeHandlerRegistry

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.

https://jena.apache.org/documentation/notes/system-initialization.html



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

"$FUSEKI_HOME/webapp"

and call the main function.

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

  Andy


Cheers,
Reto


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

You can replace Jena's DESCRIBE behavior with whatever you like:

https://jena.apache.org/documentation/query/extension.html#describe
-
handlers

ajs6f


On Mar 3, 2018, at 8:03 AM, Reto Gmür <r...@factsmission.com>

wrote:


Hi all,

I've noticed that a DESCRIBE query returns the Concise Bounded
Description

(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.


Cheers,
Reto

RE: Getting Symmetric Concise Bounded Description with Fuseki

[Reto Gmür]

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. 

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.

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

It seems that even when a DescribeHandler is provided, the default handler is 
executed as well. Is there a way to disable this?

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 node?

Cheers,
Reto

> -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
> 
> Cheers,
> Reto
> 
> > -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
> > > DescribeHandlerRegistry
> > 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.
> >
> > https://jena.apache.org/documentation/notes/system-initialization.html
> >
> > >
> > > 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
> "$FUSEKI_HOME/webapp"
> > and call the main function.
> >
> > org.apache.jena.fuseki.cmd.FusekiCmd.main(args ...)
> >
> >  Andy
> >
> > > Cheers,
> > > Reto
> > >
> > >> -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
> > >> Fuseki
> > >>
> > >> You can replace Jena's DESCRIBE behavior with whatever you like:
> > >>
> > >> https://jena.apache.org/documentation/query/extension.html#describe
> > >> -
> > >> handlers
> > >>
> > >> ajs6f
> > >>
> > >>> On Mar 3, 2018, at 8:03 AM, Reto Gmür <r...@factsmission.com>
> wrote:
> > >>>
> > >>> Hi all,
> > >>>
> > >>> I've noticed that a DESCRIBE query returns the Concise Bounded
> > >>> Description
> > >> (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.
> > >>>
> > >>> Cheers,
> > >>> Reto
> > >

RE: Getting Symmetric Concise Bounded Description with Fuseki

[Reto Gmür]

Great, it works!

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

Cheers,
Reto

> -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 DescribeHandlerRegistry
> 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.
> 
> https://jena.apache.org/documentation/notes/system-initialization.html
> 
> >
> > 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 "$FUSEKI_HOME/webapp"
> and call the main function.
> 
> org.apache.jena.fuseki.cmd.FusekiCmd.main(args ...)
> 
>  Andy
> 
> > Cheers,
> > Reto
> >
> >> -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
> >> Fuseki
> >>
> >> You can replace Jena's DESCRIBE behavior with whatever you like:
> >>
> >> https://jena.apache.org/documentation/query/extension.html#describe-
> >> handlers
> >>
> >> ajs6f
> >>
> >>> On Mar 3, 2018, at 8:03 AM, Reto Gmür <r...@factsmission.com> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I've noticed that a DESCRIBE query returns the Concise Bounded
> >>> Description
> >> (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.
> >>>
> >>> Cheers,
> >>> Reto
> >

Re: Getting Symmetric Concise Bounded Description with Fuseki

[Andy Seaborne]

On 08/03/18 16:12, Reto Gmür wrote:

Thanks for the link ajs6f.

The described method for registering with the DescribeHandlerRegistry 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.

https://jena.apache.org/documentation/notes/system-initialization.html



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 
"$FUSEKI_HOME/webapp" and call the main function.


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

Andy


Cheers,
Reto


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

You can replace Jena's DESCRIBE behavior with whatever you like:

https://jena.apache.org/documentation/query/extension.html#describe-
handlers

ajs6f


On Mar 3, 2018, at 8:03 AM, Reto Gmür <r...@factsmission.com> wrote:

Hi all,

I've noticed that a DESCRIBE query returns the Concise Bounded Description

(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.


Cheers,
Reto

RE: Getting Symmetric Concise Bounded Description with Fuseki

[Reto Gmür]

Thanks for the link ajs6f.

The described method for registering with the DescribeHandlerRegistry works if 
Fuseki is embedded. Is there a way to add a DescribeHandlerFactory to a 
stand-alone fuseki instance? ServiceLoaders come to mind.

If there isn't such a possibility, what's the best way to embed  fuseki with 
the full webapp (Fuseki UI and Admin functions)?

Cheers,
Reto

> -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 Fuseki
> 
> You can replace Jena's DESCRIBE behavior with whatever you like:
> 
> https://jena.apache.org/documentation/query/extension.html#describe-
> handlers
> 
> ajs6f
> 
> > On Mar 3, 2018, at 8:03 AM, Reto Gmür <r...@factsmission.com> wrote:
> >
> > Hi all,
> >
> > I've noticed that a DESCRIBE query returns the Concise Bounded Description
> (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.
> >
> > Cheers,
> > Reto

Re: Getting Symmetric Concise Bounded Description with Fuseki

[James Anderson]

good morning;

> On 2018-03-03, at 17:18, Andy Seaborne  wrote:
> 
> ...
> 
> DESCRIBE isn't claiming to be CBD - it does not add the reifications for 
> example. It is the bNode closure and you're right - it's in the forward 
> direction only.

as described, the result is a cbd. the cbd definition describes how to include 
information from reified statements, but does not require it to be included, 
just as it includes provisions for limiting extent.
the request is for a “symmetric concise bounded description”.

> 
>Andy
> 
> On 03/03/18 13:03, Reto Gmür wrote:
>> Hi all,
>> I've noticed that a DESCRIBE query returns the Concise Bounded Description 
>> (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.
>> Cheers,
>> Reto

Re: Getting Symmetric Concise Bounded Description with Fuseki

[Andy Seaborne]

Hi Reto,

Only be adding java code, which can be dynamically loaded, to change the 
describe handler.


A different approach is to build up a CONSTRUCT successively, 
introspecting on the data eachtime.


start with

CONSTRUCT WHERE { ?x ?p ?subject }

then see which properties have blank node subjects and expand to:

CONSTRUCT WHERE { ?x ?p ?subject .
  ?o1 :someProperty1 ?x .
  ?o2 :someProperty2 ?x . }

adding to the pattern to expand it out. That way, it re-locates the 
blank nodes each time.


DESCRIBE isn't claiming to be CBD - it does not add the reifications for 
example. It is the bNode closure and you're right - it's in the forward 
direction only.


Andy

On 03/03/18 13:03, Reto Gmür wrote:

Hi all,

I've noticed that a DESCRIBE query returns the Concise Bounded Description 
(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.

Cheers,
Reto

Re: Getting Symmetric Concise Bounded Description with Fuseki

[ajs6f]

You can replace Jena's DESCRIBE behavior with whatever you like:

https://jena.apache.org/documentation/query/extension.html#describe-handlers

ajs6f

> On Mar 3, 2018, at 8:03 AM, Reto Gmür  wrote:
> 
> Hi all,
> 
> I've noticed that a DESCRIBE query returns the Concise Bounded Description 
> (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.
> 
> Cheers,
> Reto