Hi Sascha, Andy, Did you have a chance to take a look at this? If the solution seems sensible, I'd like to improve the Jena documentation as well (for instance here <https://jena.apache.org/documentation/fuseki2/fuseki-server-protocol.html#datasets-and-services> and here <https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html>).
All the best, Nicola Il giorno gio 30 apr 2020 alle ore 23:03 Nicola Vitucci < [email protected]> ha scritto: > Hey Sascha, Andy, > > Here is my blog post: > 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 >
