Hello Nicola,
thank you again for this nice summary about Fuseki configuration with reasoning. I was able to reproduce your findings: 1) Adding data to the base named graph doesn’t cause a complete inference* for the linked inf model. 2) Adding data to inf model triggers the inference. 3) A restart is required to trigger the complete inference on the default graph that is a UnionGraph of all named graphs. * Incomplete inference: It adds some triples to the inf graph (see step 5 in the attached CSV file). For example, an owl:sameAs statement appeared in the query results. The inference was, however, incomplete because no inferred hierarchical relations were added. Do you mean this by “no, or limited, inference”? Your blog post helped me to better understand the design of Fuseki datasets with reasoning. Unfortunately, it didn’t solve our specific use case. Our plan was to store contextual data in separate, named graphs and inference over the UnionGraph aggregation whenever new data is added to one of the named graphs. Using your approach, we would be able to do reasoning on each named graph separately and join the results in the default graph. But this would not automatically evaluate relations between the different graphs; It would still require a restart. Here are my detailed results for the “Many named graphs” example. I monitored the number of triples in the different named graphs (attached CSV file). In step 3, the inference was incomplete. I found no hierarchical relation statements in the id:inf graph (missing: “ont:mySuperProp id:x id:inf“ and “rdf:type ont:MySuperType id:inf”). The two missing statements only showed up after a restart. In step 5, the triple “owl:sameAs id:d” was added. In step 6, I think it was MySubType, not MySuperType. Again in step 11, one inferred triple was present: owl:sameAs id:XXX. After a restart (step 12), the inference was complete. Best regards Sascha >-----Original Message----- >From: Nicola Vitucci <nicola.vitu...@gmail.com> >Sent: Friday, May 1, 2020 12:03 AM >To: users@jena.apache.org >Subject: Re: Fuseki inference not triggered with incoming data > >Hey Sascha, Andy, > >Here is my blog post: >https://apothem.blog/apache-fuseki-adding-reasoning-and-full-text-search-<https://apothem.blog/apache-fuseki-adding-reasoning-and-full-text-search-capabilities-to-a-dataset.html> >capabilities-to-a-dataset.html<https://apothem.blog/apache-fuseki-adding-reasoning-and-full-text-search-capabilities-to-a-dataset.html> > >It may require some polishing but i'd like your feedback, especially if it >can help Sascha to solve his problem. It would be great if you could >replicate my results, and/or confirm that my understanding is correct. > >For inference, I've been asking what level of inference people are >> really using. We could have a stateless RDFS-class reasoner that sits on >> any graph/dataset and always goes back to the base data. No, or very >> short term, caching. >> >> That would be less capable, and slower (but how much? not much in >> practice?) but it will scale, will fit with transactions and data >> visibility, and will see changes in the data as they occur. >> > >This can probably be enough for many use cases (rdf4j does something >similar already, if I understand your suggestion), but what I see more and >more often, and what sometimes I need as well, is some level of support for >owl:sameAs and some other OWL constructs such as owl:equivalentClass and >owl:equivalentProperty. That said, the scalability would make it quite >appealing though, and a simple switch during the dataset creation phase >("add RDFS reasoning?") would make it a very useful feature. > > >> Knowing the generation of the data seems to me at the moment to be >worth >> adding to the dataset interface itself. A simple "what version am I >> looking at?" method. It could be a counter (sequential) or give every >> write transaction a UUID and be able to fetch the generation of the data >> the current read transaction is acting on. >> > >This would also be quite useful in its own right. > >Nicola
