You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID> on 2018/09/28 14:41:40 UTC
RE: get derivations via Fuseki
Hi all,
I would like to include the derivation service I describe below in the standalone version of Fuseki (i.e. started by calling the ./fuseki-server script). Is this possible? I assume not, since in this JIRA-1435 issue (https://issues.apache.org/jira/browse/JENA-1435), I read:
"At least initially, this extensibility is only supported for the programmatic Fuseki server and have a programmatic configuration API."
Can anyone confirm it is not possible to load my custom service if I use the fuseki-server script? Or can I maybe use "ja:loadClass" from a configuration.ttl file to load it?
Thanks for the help!
Regards, Barry
-----Original Message-----
From: Nouwt, B. (Barry) <ba...@tno.nl>
Sent: maandag 28 mei 2018 09:49
To: users@jena.apache.org
Subject: RE: get derivations via Fuseki
Hi Andy,
Thanks for the clarification.
Regarding "What is also good to know is whether Jena has the right extension points." I expect some modifications to the Apache Jena source are required. See my previous mail where I have some remarks/questions:
- 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.
Regards,
Barry
B. (Barry) Nouwt
Medior Innovator Semantic Technology
Connected Business
T +31 (0)88 866 56 91
M +31 (0)64 977 53 56
E barry.nouwt@tno.nl
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
-----Original Message-----
From: Andy Seaborne <an...@apache.org>
Sent: zondag 27 mei 2018 17:29
To: users@jena.apache.org
Subject: Re: get derivations via Fuseki
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) <ba...@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 <an...@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:opdc
>> b
>> 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.
>>
RE: get derivations via Fuseki
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID>.
Hey Andy, thanks! I used the web.xml approach (and adding my custom code to the classpath) to register my own ContextListener and can now access the ServiceDispatchRegistry to register my custom 'derivation' operation. The DatasetAccessPointRegistry allows adding this 'derivation' operation to any existing InfGraph datasets (see attached screenshot of Fuseki). I also enable derivation logging for the available datasets here, because it is not possible to do this from Fuseki's configuration files.
Using a http call like "http://localhost:3030/dairy/derivation?triple=(<http://tno.nl/B> <http://tno.nl/departure> 'later')" returns the derivation text of that triple, for example:
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>)
Thanks for your help and below a list of things to improve this solution even further.
Regards, Barry
Improvements:
- allow derivation logging to be enabled from a Fuseki .ttl configuration file.
- allow custom services to be registered from a Fuseki .ttl configuration file.
- allow derivation logging check (whether it is enabled/disabled) from the Jena Rulesys API.
- allow navigation of derivation logging tree using the Jena Rulesys API. Currently, you can just get a string with the derivation text above. However, it would be easier to parse this into our specific RDF format (in terms of our Explainability Ontology) if we could access the internal structure of a derivation.
-----Original Message-----
From: Andy Seaborne <an...@apache.org>
Sent: dinsdag 2 oktober 2018 13:13
To: users@jena.apache.org
Subject: Re: get derivations via Fuseki
On 02/10/18 07:37, Nouwt, B. (Barry) wrote:
> Hi Andy, thanks for the extended reply.
>
> It's unclear to me, from your description below, whether the "full" server (that starts via the bash script) also uses the web.xml when starting? Since this web.xml file is normally only used for deployment on a servlet container (like tomcat).
Yes, it does.
The standalone packaging of the full server is jetty+the webapp and does normal webapp startup processing web.xml.
Andy
>
> Anyway, if I understand you correctly, my only option is adding custom code to the end of FusekiServerListener.serverInitialization(). Although not ideal, for demo purposes this suffices.
>
> Thanks for your help!
>
> Barry
>
> B. (Barry) Nouwt
> Medior Innovator Semantic Technology
> Connected Business
> T +31 (0)88 866 56 91
> M +31 (0)64 977 53 56
> E barry.nouwt@tno.nl
>
> 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.
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: zondag 30 september 2018 11:56
> To: users@jena.apache.org
> Subject: Re: get derivations via Fuseki
>
> Hi Barry,
>
> If you can use the embedded server, it is easier to setup with
> extended functionality, as per JENA-1435, but then no UI and admin
>
> In Jena 3.9.0 the embedded server is renamed as "main", and the
> UI/admin/core engine server is the "full" or "webapp" server [*]
>
> The mechanisms of JENA-1435 will work in the full server (even while
> running!) but I can't think of a way to get the ServletContext, which is used to store the Fuseki configuration, which isn't either a code change or a change to web.xml.
>
> The code change is to FusekiServerListener.serverInitialization. At the end of that method, call your code. (For a web.xml chnage, add your own ServletContextListener to after Fuseki's).
>
> That gets the ServletContext; from there get the
> ServiceDispatchRegistry
>
> ServiceDispatchRegistry registry =
> ServiceDispatchRegistry.get(ServletContext servletContext)
>
> and then manipulate registry to add your service.
>
> See around FusekiServer.java#L474 for manipulating the ServiceDispatchRegistry.
>
> https://github.com/apache/jena/blob/aef35ee50eef9e0820d23d5ba184906b17
> 7a5c15/jena-fuseki2/jena-fuseki-main/src/main/java/org/apache/jena/fus
> eki/main/FusekiServer.java#L474
>
>
> For the full server, you need to put your code onto the classpath of the server so instead of running the standalone server jar with "-jar"
> (which is what the script does), you need to use the combined
> fuseki-server.jar jar ad one element of the classpath and your
> code+extra dependencies then call "main":
>
> java -cp fuseki-server-mod.jar:YourCode.jar:other.jar \
> org.apache.jena.fuseki.cmd.FusekiCmd "$@"
>
> If you use the WAR file, you'll need to unpack and repack it with your code in it.
>
>
> If there is a way to get the ServletContext, "ja:loadClass" would work.
> However, the change in JNA-1435 is to go from a global registry to a
> one per ServletContext (allows for multiple servers in one JVM).
>
> Or run a modified Fuseki with call to your code in
> FusekiServerListener.serverInitialization.
>
> ---
>
> http://jena.apache.org/documentation/fuseki2/fuseki-embedded.html
>
> src/test/java/org/apache/jena/fuseki/embedded/examples/ExtendFuseki_Ad
> dService_1.java
>
> ---
>
> Andy
>
> [*] Because of the way webapps start up in servlet containers like
> Tomcat, the two servers have different initialization code.
>
> The difference in the two forms comes down to the fact that the full
> server has state on disk (the run/ area) where it manages datasets,
> and the main server is given datasets to publish.
>
> Some of the UI applies to the "main" server and could be shared, some
> does not (e.g. adding datasets). Something for the future maybe.
>
> I'm currently engaged in a project deploying Fuseki into a cloud
> environment as a (micro)service, deployed by automation etc etc.
> No UI; it's accessed by other services.
>
> On 28/09/18 15:41, Nouwt, B. (Barry) wrote:
>> Hi all,
>>
>> I would like to include the derivation service I describe below in the standalone version of Fuseki (i.e. started by calling the ./fuseki-server script). Is this possible? I assume not, since in this JIRA-1435 issue (https://issues.apache.org/jira/browse/JENA-1435), I read:
>>
>> "At least initially, this extensibility is only supported for the programmatic Fuseki server and have a programmatic configuration API."
>>
>> Can anyone confirm it is not possible to load my custom service if I use the fuseki-server script? Or can I maybe use "ja:loadClass" from a configuration.ttl file to load it?
>>
>> Thanks for the help!
>>
>> Regards, Barry
>>
>> -----Original Message-----
>> From: Nouwt, B. (Barry) <ba...@tno.nl>
>> Sent: maandag 28 mei 2018 09:49
>> To: users@jena.apache.org
>> Subject: RE: get derivations via Fuseki
>>
>> Hi Andy,
>>
>> Thanks for the clarification.
>>
>> Regarding "What is also good to know is whether Jena has the right extension points." I expect some modifications to the Apache Jena source are required. See my previous mail where I have some remarks/questions:
>>
>> - 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.
>>
>> Regards,
>>
>> Barry
>>
>> B. (Barry) Nouwt
>> Medior Innovator Semantic Technology
>> Connected Business
>> T +31 (0)88 866 56 91
>> M +31 (0)64 977 53 56
>> E barry.nouwt@tno.nl
>>
>> 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
>>
>> -----Original Message-----
>> From: Andy Seaborne <an...@apache.org>
>> Sent: zondag 27 mei 2018 17:29
>> To: users@jena.apache.org
>> Subject: Re: get derivations via Fuseki
>>
>>
>>
>> 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) <ba...@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 <an...@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:op
>>>> dc
>>>> b
>>>> 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.
>>>>
Re: get derivations via Fuseki
Posted by Andy Seaborne <an...@apache.org>.
On 02/10/18 07:37, Nouwt, B. (Barry) wrote:
> Hi Andy, thanks for the extended reply.
>
> It's unclear to me, from your description below, whether the "full" server (that starts via the bash script) also uses the web.xml when starting? Since this web.xml file is normally only used for deployment on a servlet container (like tomcat).
Yes, it does.
The standalone packaging of the full server is jetty+the webapp and does
normal webapp startup processing web.xml.
Andy
>
> Anyway, if I understand you correctly, my only option is adding custom code to the end of FusekiServerListener.serverInitialization(). Although not ideal, for demo purposes this suffices.
>
> Thanks for your help!
>
> Barry
>
> B. (Barry) Nouwt
> Medior Innovator Semantic Technology
> Connected Business
> T +31 (0)88 866 56 91
> M +31 (0)64 977 53 56
> E barry.nouwt@tno.nl
>
> 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.
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: zondag 30 september 2018 11:56
> To: users@jena.apache.org
> Subject: Re: get derivations via Fuseki
>
> Hi Barry,
>
> If you can use the embedded server, it is easier to setup with extended functionality, as per JENA-1435, but then no UI and admin
>
> In Jena 3.9.0 the embedded server is renamed as "main", and the UI/admin/core engine server is the "full" or "webapp" server [*]
>
> The mechanisms of JENA-1435 will work in the full server (even while
> running!) but I can't think of a way to get the ServletContext, which is used to store the Fuseki configuration, which isn't either a code change or a change to web.xml.
>
> The code change is to FusekiServerListener.serverInitialization. At the end of that method, call your code. (For a web.xml chnage, add your own ServletContextListener to after Fuseki's).
>
> That gets the ServletContext; from there get the ServiceDispatchRegistry
>
> ServiceDispatchRegistry registry =
> ServiceDispatchRegistry.get(ServletContext servletContext)
>
> and then manipulate registry to add your service.
>
> See around FusekiServer.java#L474 for manipulating the ServiceDispatchRegistry.
>
> https://github.com/apache/jena/blob/aef35ee50eef9e0820d23d5ba184906b177a5c15/jena-fuseki2/jena-fuseki-main/src/main/java/org/apache/jena/fuseki/main/FusekiServer.java#L474
>
>
> For the full server, you need to put your code onto the classpath of the server so instead of running the standalone server jar with "-jar"
> (which is what the script does), you need to use the combined fuseki-server.jar jar ad one element of the classpath and your
> code+extra dependencies then call "main":
>
> java -cp fuseki-server-mod.jar:YourCode.jar:other.jar \
> org.apache.jena.fuseki.cmd.FusekiCmd "$@"
>
> If you use the WAR file, you'll need to unpack and repack it with your code in it.
>
>
> If there is a way to get the ServletContext, "ja:loadClass" would work.
> However, the change in JNA-1435 is to go from a global registry to a one
> per ServletContext (allows for multiple servers in one JVM).
>
> Or run a modified Fuseki with call to your code in
> FusekiServerListener.serverInitialization.
>
> ---
>
> http://jena.apache.org/documentation/fuseki2/fuseki-embedded.html
>
> src/test/java/org/apache/jena/fuseki/embedded/examples/ExtendFuseki_AddService_1.java
>
> ---
>
> Andy
>
> [*] Because of the way webapps start up in servlet containers like
> Tomcat, the two servers have different initialization code.
>
> The difference in the two forms comes down to the fact that the full
> server has state on disk (the run/ area) where it manages datasets, and
> the main server is given datasets to publish.
>
> Some of the UI applies to the "main" server and could be shared, some
> does not (e.g. adding datasets). Something for the future maybe.
>
> I'm currently engaged in a project deploying Fuseki into a cloud
> environment as a (micro)service, deployed by automation etc etc.
> No UI; it's accessed by other services.
>
> On 28/09/18 15:41, Nouwt, B. (Barry) wrote:
>> Hi all,
>>
>> I would like to include the derivation service I describe below in the standalone version of Fuseki (i.e. started by calling the ./fuseki-server script). Is this possible? I assume not, since in this JIRA-1435 issue (https://issues.apache.org/jira/browse/JENA-1435), I read:
>>
>> "At least initially, this extensibility is only supported for the programmatic Fuseki server and have a programmatic configuration API."
>>
>> Can anyone confirm it is not possible to load my custom service if I use the fuseki-server script? Or can I maybe use "ja:loadClass" from a configuration.ttl file to load it?
>>
>> Thanks for the help!
>>
>> Regards, Barry
>>
>> -----Original Message-----
>> From: Nouwt, B. (Barry) <ba...@tno.nl>
>> Sent: maandag 28 mei 2018 09:49
>> To: users@jena.apache.org
>> Subject: RE: get derivations via Fuseki
>>
>> Hi Andy,
>>
>> Thanks for the clarification.
>>
>> Regarding "What is also good to know is whether Jena has the right extension points." I expect some modifications to the Apache Jena source are required. See my previous mail where I have some remarks/questions:
>>
>> - 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.
>>
>> Regards,
>>
>> Barry
>>
>> B. (Barry) Nouwt
>> Medior Innovator Semantic Technology
>> Connected Business
>> T +31 (0)88 866 56 91
>> M +31 (0)64 977 53 56
>> E barry.nouwt@tno.nl
>>
>> 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
>>
>> -----Original Message-----
>> From: Andy Seaborne <an...@apache.org>
>> Sent: zondag 27 mei 2018 17:29
>> To: users@jena.apache.org
>> Subject: Re: get derivations via Fuseki
>>
>>
>>
>> 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) <ba...@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 <an...@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:opdc
>>>> b
>>>> 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.
>>>>
RE: get derivations via Fuseki
Posted by "Nouwt, B. (Barry)" <ba...@tno.nl.INVALID>.
Hi Andy, thanks for the extended reply.
It's unclear to me, from your description below, whether the "full" server (that starts via the bash script) also uses the web.xml when starting? Since this web.xml file is normally only used for deployment on a servlet container (like tomcat).
Anyway, if I understand you correctly, my only option is adding custom code to the end of FusekiServerListener.serverInitialization(). Although not ideal, for demo purposes this suffices.
Thanks for your help!
Barry
B. (Barry) Nouwt
Medior Innovator Semantic Technology
Connected Business
T +31 (0)88 866 56 91
M +31 (0)64 977 53 56
E barry.nouwt@tno.nl
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.
-----Original Message-----
From: Andy Seaborne <an...@apache.org>
Sent: zondag 30 september 2018 11:56
To: users@jena.apache.org
Subject: Re: get derivations via Fuseki
Hi Barry,
If you can use the embedded server, it is easier to setup with extended functionality, as per JENA-1435, but then no UI and admin
In Jena 3.9.0 the embedded server is renamed as "main", and the UI/admin/core engine server is the "full" or "webapp" server [*]
The mechanisms of JENA-1435 will work in the full server (even while
running!) but I can't think of a way to get the ServletContext, which is used to store the Fuseki configuration, which isn't either a code change or a change to web.xml.
The code change is to FusekiServerListener.serverInitialization. At the end of that method, call your code. (For a web.xml chnage, add your own ServletContextListener to after Fuseki's).
That gets the ServletContext; from there get the ServiceDispatchRegistry
ServiceDispatchRegistry registry =
ServiceDispatchRegistry.get(ServletContext servletContext)
and then manipulate registry to add your service.
See around FusekiServer.java#L474 for manipulating the ServiceDispatchRegistry.
https://github.com/apache/jena/blob/aef35ee50eef9e0820d23d5ba184906b177a5c15/jena-fuseki2/jena-fuseki-main/src/main/java/org/apache/jena/fuseki/main/FusekiServer.java#L474
For the full server, you need to put your code onto the classpath of the server so instead of running the standalone server jar with "-jar"
(which is what the script does), you need to use the combined fuseki-server.jar jar ad one element of the classpath and your
code+extra dependencies then call "main":
java -cp fuseki-server-mod.jar:YourCode.jar:other.jar \
org.apache.jena.fuseki.cmd.FusekiCmd "$@"
If you use the WAR file, you'll need to unpack and repack it with your code in it.
If there is a way to get the ServletContext, "ja:loadClass" would work.
However, the change in JNA-1435 is to go from a global registry to a one
per ServletContext (allows for multiple servers in one JVM).
Or run a modified Fuseki with call to your code in
FusekiServerListener.serverInitialization.
---
http://jena.apache.org/documentation/fuseki2/fuseki-embedded.html
src/test/java/org/apache/jena/fuseki/embedded/examples/ExtendFuseki_AddService_1.java
---
Andy
[*] Because of the way webapps start up in servlet containers like
Tomcat, the two servers have different initialization code.
The difference in the two forms comes down to the fact that the full
server has state on disk (the run/ area) where it manages datasets, and
the main server is given datasets to publish.
Some of the UI applies to the "main" server and could be shared, some
does not (e.g. adding datasets). Something for the future maybe.
I'm currently engaged in a project deploying Fuseki into a cloud
environment as a (micro)service, deployed by automation etc etc.
No UI; it's accessed by other services.
On 28/09/18 15:41, Nouwt, B. (Barry) wrote:
> Hi all,
>
> I would like to include the derivation service I describe below in the standalone version of Fuseki (i.e. started by calling the ./fuseki-server script). Is this possible? I assume not, since in this JIRA-1435 issue (https://issues.apache.org/jira/browse/JENA-1435), I read:
>
> "At least initially, this extensibility is only supported for the programmatic Fuseki server and have a programmatic configuration API."
>
> Can anyone confirm it is not possible to load my custom service if I use the fuseki-server script? Or can I maybe use "ja:loadClass" from a configuration.ttl file to load it?
>
> Thanks for the help!
>
> Regards, Barry
>
> -----Original Message-----
> From: Nouwt, B. (Barry) <ba...@tno.nl>
> Sent: maandag 28 mei 2018 09:49
> To: users@jena.apache.org
> Subject: RE: get derivations via Fuseki
>
> Hi Andy,
>
> Thanks for the clarification.
>
> Regarding "What is also good to know is whether Jena has the right extension points." I expect some modifications to the Apache Jena source are required. See my previous mail where I have some remarks/questions:
>
> - 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.
>
> Regards,
>
> Barry
>
> B. (Barry) Nouwt
> Medior Innovator Semantic Technology
> Connected Business
> T +31 (0)88 866 56 91
> M +31 (0)64 977 53 56
> E barry.nouwt@tno.nl
>
> 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
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: zondag 27 mei 2018 17:29
> To: users@jena.apache.org
> Subject: Re: get derivations via Fuseki
>
>
>
> 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) <ba...@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 <an...@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:opdc
>>> b
>>> 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.
>>>
Re: get derivations via Fuseki
Posted by Andy Seaborne <an...@apache.org>.
Hi Barry,
If you can use the embedded server, it is easier to setup with extended
functionality, as per JENA-1435, but then no UI and admin
In Jena 3.9.0 the embedded server is renamed as "main", and the
UI/admin/core engine server is the "full" or "webapp" server [*]
The mechanisms of JENA-1435 will work in the full server (even while
running!) but I can't think of a way to get the ServletContext, which is
used to store the Fuseki configuration, which isn't either a code change
or a change to web.xml.
The code change is to FusekiServerListener.serverInitialization. At the
end of that method, call your code. (For a web.xml chnage, add your own
ServletContextListener to after Fuseki's).
That gets the ServletContext; from there get the ServiceDispatchRegistry
ServiceDispatchRegistry registry =
ServiceDispatchRegistry.get(ServletContext servletContext)
and then manipulate registry to add your service.
See around FusekiServer.java#L474 for manipulating the
ServiceDispatchRegistry.
https://github.com/apache/jena/blob/aef35ee50eef9e0820d23d5ba184906b177a5c15/jena-fuseki2/jena-fuseki-main/src/main/java/org/apache/jena/fuseki/main/FusekiServer.java#L474
For the full server, you need to put your code onto the classpath of the
server so instead of running the standalone server jar with "-jar"
(which is what the script does), you need to use the combined
fuseki-server.jar jar ad one element of the classpath and your
code+extra dependencies then call "main":
java -cp fuseki-server-mod.jar:YourCode.jar:other.jar \
org.apache.jena.fuseki.cmd.FusekiCmd "$@"
If you use the WAR file, you'll need to unpack and repack it with your
code in it.
If there is a way to get the ServletContext, "ja:loadClass" would work.
However, the change in JNA-1435 is to go from a global registry to a one
per ServletContext (allows for multiple servers in one JVM).
Or run a modified Fuseki with call to your code in
FusekiServerListener.serverInitialization.
---
http://jena.apache.org/documentation/fuseki2/fuseki-embedded.html
src/test/java/org/apache/jena/fuseki/embedded/examples/ExtendFuseki_AddService_1.java
---
Andy
[*] Because of the way webapps start up in servlet containers like
Tomcat, the two servers have different initialization code.
The difference in the two forms comes down to the fact that the full
server has state on disk (the run/ area) where it manages datasets, and
the main server is given datasets to publish.
Some of the UI applies to the "main" server and could be shared, some
does not (e.g. adding datasets). Something for the future maybe.
I'm currently engaged in a project deploying Fuseki into a cloud
environment as a (micro)service, deployed by automation etc etc.
No UI; it's accessed by other services.
On 28/09/18 15:41, Nouwt, B. (Barry) wrote:
> Hi all,
>
> I would like to include the derivation service I describe below in the standalone version of Fuseki (i.e. started by calling the ./fuseki-server script). Is this possible? I assume not, since in this JIRA-1435 issue (https://issues.apache.org/jira/browse/JENA-1435), I read:
>
> "At least initially, this extensibility is only supported for the programmatic Fuseki server and have a programmatic configuration API."
>
> Can anyone confirm it is not possible to load my custom service if I use the fuseki-server script? Or can I maybe use "ja:loadClass" from a configuration.ttl file to load it?
>
> Thanks for the help!
>
> Regards, Barry
>
> -----Original Message-----
> From: Nouwt, B. (Barry) <ba...@tno.nl>
> Sent: maandag 28 mei 2018 09:49
> To: users@jena.apache.org
> Subject: RE: get derivations via Fuseki
>
> Hi Andy,
>
> Thanks for the clarification.
>
> Regarding "What is also good to know is whether Jena has the right extension points." I expect some modifications to the Apache Jena source are required. See my previous mail where I have some remarks/questions:
>
> - 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.
>
> Regards,
>
> Barry
>
> B. (Barry) Nouwt
> Medior Innovator Semantic Technology
> Connected Business
> T +31 (0)88 866 56 91
> M +31 (0)64 977 53 56
> E barry.nouwt@tno.nl
>
> 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
>
> -----Original Message-----
> From: Andy Seaborne <an...@apache.org>
> Sent: zondag 27 mei 2018 17:29
> To: users@jena.apache.org
> Subject: Re: get derivations via Fuseki
>
>
>
> 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) <ba...@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 <an...@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:opdc
>>> b
>>> 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.
>>>