On 17/05/18 10:11, Nouwt, B. (Barry) wrote:
Hi all,

I've successfully modified the TestFusekiCustomOperation example to a working 
DerivationService test. I can request the derivation of some triple using the 
following request:

http://localhost:3030/ds/derivation?triple=(<http://tno.nl/B> <http://tno.nl/departure> 
"later")

and it returns the derivation log text:

Rule calcETD concluded (<http://tno.nl/B> <http://tno.nl/departure> 'later') <-
     Fact (<http://tno.nl/A> rdf:type <http://tno.nl/Ship>)
     Rule calcETA concluded (<http://tno.nl/A> <http://tno.nl/arrival> 'late') 
<-
         Fact (<http://tno.nl/A> rdf:type <http://tno.nl/Ship>)
         Fact (<http://tno.nl/A> <http://tno.nl/speed> 'Slow')
     Fact (<http://tno.nl/B> rdf:type <http://tno.nl/Truck>)
     Fact (<http://tno.nl/B> <http://tno.nl/picksUpFrom> <http://tno.nl/A>)

Of course, the questions mentioned in an earlier mail remain, but at least I 
know it's possible. Next, I will make it more user friendly and generic so we 
can include it in our semantic platform.

@Andy: is the Apache Jena project interested in getting the code when I have a 
more generic version? Or would it be better to keep the code separate from 
Apache Jena? If Apache Jena is interested, I should probably investigate how 
this process works (since I have no experience yet with contributing to Apache 
Jena projects).

Barry - the project is always interested and it doesn't sound too big.

What is also good to know is whether Jena has the right extension points.

General comments on additional functionality:

What any Apache project isn't, by default, is a place to transfer code for future maintenance by the project team. If some on the team are interested great, but it is better to know there is interest. Any significant sized contribution will need some degree of on-going interest to keep it maintained.

By labelling a Github project (e.g.) "Powered by Apache Jena", search engines will be able to find it. Not everything has to be part of one humongous build.

    Andy


Regards, Barry

-----Original Message-----
From: Nouwt, B. (Barry) <barry.no...@tno.nl>
Sent: dinsdag 15 mei 2018 17:55
To: users@jena.apache.org
Subject: RE: get derivations via Fuseki

Hi Andy, thanks for your reply.

I took a look at the TestFusekiCustomOperation example and it looks quite 
straightforward. I started with a first implementation and the following 
questions arised:

- The Derivation interface does not allow inspecting the derivation via code 
for a particular triple. It only declares a toString() and printTrace() method. 
To be able to generate the derivation log in a JSON or RDF format, this 
interface would probably need to be adapted (or we would need to cast a 
Derivation object to some implementation of this interface making the code less 
reasoner independent).

- The InfGraph interface does not allow checking whether derivation logging is 
enabled. You can only enable/disable it using the above setDerivationLogging() 
method. There is a method in BasicForwardRuleInfGraph.shouldLogDerivations(), 
though. Is there some other way to check whether it is enabled? Or should 
InfGraph get an additional method?

- Since the derivations can take up quite some memory, you need to enable 
derivation logging on an InfGraph using the setDerivationLogging(true) method. 
Can the DerivationService that I'm building call this method on the InfGraph 
when the Fuseki dataset is loaded? Or would it be better to modify the InfGraph 
Assembler code to configure it from a Fuseki configuration file? In that case a 
user would need to remember to enable derivation logging, when it wants to use 
the derivation service.

So, I think some modifications to the Apache Jena source are required to enable 
the derivation service feature.

Regards,

Barry


-----Original Message-----
From: Andy Seaborne <a...@apache.org>
Sent: donderdag 10 mei 2018 14:48
To: users@jena.apache.org
Subject: Re: get derivations via Fuseki

Hi Barry,

On 08/05/18 16:53, Nouwt, B. (Barry) wrote:
Hello everyone,

I know Apache Jena allows a developer to access the derivation of an inferred 
triple using the InfModel.getDerivation() method. Can I also access this 
explanation via Apache Jena Fuseki GUI?
I have configured Apache Jena Fuseki in such a way that the GenericRuleReasoner 
infers new triples based on my dataset and a few rules. I am able to fire a 
SPARQL query via Fuseki GUI and the answer includes the inferred triples as 
expected. For our project, we would like to access the derivation of an 
inferred triple via the GUI (as is possible in, for example, Protégé).


    *   Is this already possible in Fuseki? If not;
    *   Would it be interesting if we contribute to Fuseki to add such a 
feature? And if so;
    *   Are there any relevant pointers to get us started?

For example, I noticed (in the 3.7.0 release) the following JIRA that sounds 
like a starting point:

JENA-1435: Provide extensibility of Fuseki with new services.
It is now possible to add custom services to a Fuseki service, not
just the services provided by the Fuseki distribution.

Source:
https://jena.markmail.org/search/?q=3.7.0#query:3.7.0+page:1+mid:opdcb
i6qhrim4bsv+state:results

If it is indeed possible to extend Fuseki with custom services, it might be 
possible to introduce a new service called 'derivation' that, given a triple, 
produces the derivation log for that triple. It would produce the explanation 
in some JSON format. The Apache Jena Fuseki GUI could parse this result and 
show it on screen.

So, my first question is: is it already possible to retrieve the derivation log 
using Apache Jena Fuseki and if so, how?

There isn't such a feature.

My follow-up question: would it be interesting if we could contribute such a 
feature to Fuseki?

Yes - and it should be possible to develop such a feature without needing to 
modifying the Fuseki source. That's the point of JENA-1435.

There are some tests in TestFusekiCustomOperation

It is easier to develop functionality using the programmatic, same-JVM form of 
the Fuseki server because the FusekiServer.Builder.

      Andy


Regards,

Barry

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. TNO accepts no liability 
for the content of this e-mail, for the manner in which you use it and for 
damage of any kind resulting from the risks inherent to the electronic 
transmission of messages.

Reply via email to