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: <urn:dydra:simple-concise-bounded-description>

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 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, 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.ht
> > >>> ml
> > >>>
> > >>>>
> > >>>> 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#describ
> > >>>>> e
> > >>>>> -
> > >>>>> 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
> > >>>>
>

Reply via email to