Virtuoso Integration

12 views
Skip to first unread message

Jan Dědek

unread,
Mar 14, 2017, 5:15:57 AM3/14/17
to semanticturkey-developer
Dear all,
currently, we are experimenting with VocBench and would like to use it in our company (datlowe.cz) for our internal vocabulary management as well as translation of execting ones (e.g. SNOMED).

We have some good experience with Virtuoso Open-Source tripplestore. So I would like to ask about the current satus of Virtuoso integration with SemanticTurkey and VocBench.

I found some notes on the web that the integration is possible ("Virtuoso necessarily requires a dedicated client") but no further references about how to accomplish that. I will be gratefull for any link, guide or advice in this direction. 

We are able to do some limited developmenet and contribute to your projects if thre is nothing complete and ready yet.

Thanks for any answer and 
sorry for cross-posting (vocbench-user, semanticturkey-user, semanticturkey-developer), I don't know, which list is the right one...

Armando Stellato

unread,
Mar 14, 2017, 6:14:47 AM3/14/17
to semanticturk...@googlegroups.com

Dear Jan,

 

no problem for the crossposting: btw, the developer list is for development aspects (e.g. if you are a developer and want to modify/extend ST or VB), while the user is for anything that users can directly deal with.

In your case, this is a feature request, so it stays well on the user list :-)

Concerning ST vs VB lists, we will maybe reorganize things when VB3 is definitely out. In the past, we had the ST user list covering mostly the use of the Firefox plugin. Now, with VB3 taking place as the ST frontend both for desktop and collaborative use, we might decide to drop a list, or keep both in any case (ST can be used as a service-based platform for RDF management, potentially powering other kind of front-end applications, and that’s where the ST users will fall).

 

Getting back to your request: VocBench 2 (or better, Semantic Turkey behind it) access to RDF was based on an abstraction level (OWLART, [1]). In the past years, we have developed a few implementations of this layer based on existing popular middlewares (Jena, Sesame, Androjena etc…), including specific clients based on any of the above middleware but requiring dedicated libraries (e.g. Virtuoso and Allegrograph clients). The reference you found is referring to that.

 

So, after years on ST/VB2 in which we had to keep up with evolutions of those middlewares, always forced to keep the least common denominator among them, we decided it was time to take a stance, stick to a specific technology and enjoy all the advantages of it without any need for further layers/wrappers. RDF4J [2] has been the framework of choice for us, so VB3 (or, again, the new version of ST behind it) will use natively RDF4J and provide connection to any triple store compliant with it. Even more, some advanced features (history and versioning, however optional for any project) will require the repository to be adopting the SailStack mechanism, as we had to adopt a common interface for data which is requested-to-be/factually modified in the repository.

 

As of what will be developed, the feature requests (end-user ones) for VocBench are so many that, consistently with the above choice of sticking to RDF4J, we will invest minimal effort on trying to catch up with repositories not satisfying the above requirements. Consider also that, despite all the standardization efforts, different triple stores can have very different requirements even after the low-level technicalities are dealt with, e.g. some features of SPARQL could be not supported, SPARQL query resolution and optimization is not a unique path, and an efficient query on one triple store could be dramatically slow on another one etc… Consider that the queries on ST are all but trivial, and in our experience with VB2 we have seen many a service causing problems when the triple store was changed ;-)

 

Anyway, if you want to investigate on adding support for Virtuoso (or any other triple store) to ST (and thus VB), I recommend to start from below: the specific triple store, its interfacing with RDF4J, the required clients (if any) and finally how to include it in ST/VB. For the last part, we can surely provide support and, despite what I said before in term of priorities, we will surely be happy to widen the support for other triple stores.

 

Some useful links:

 

·         http://rdf4j.org/about/rdf4j-databases/ directly from RDF4J, reporting on compatibility with RDF4J. Consider that RDF4J has taken over Sesame2 relatively recently, and some triple store still have to move to the new version. However, RDF4J is the future of Sesame and not a long time will pass before all the triple stores previously supporting Sesame will move to RDF4J.

 

·         https://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtSesame2Provider    mmm..here it seems good news! They report to be compliant with RDF4J

 

·         Semantic turkey developer mailing list (semanticturk...@googlegroups.com)  when ST was based on OWLART, we had extension points for plugging new RDF technologies. Now we are hard-wiring specific solutions (e.g. GraphDB [3], which is already compliant with RDF4J and its SailStack mechanism) so, once you deal with the above, you might ask us where to modify code for adding specific support for another triple store. As of the move to RDF4J, we are currently developing this part almost from scratch, so it’s better to update each other when you come to this point.

 

Cheers,


Armando

 

[1] http://art.uniroma2.it/owlart/

[2] http://rdf4j.org/

[3] http://ontotext.com/products/graphdb/

 

 

 

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "semanticturkey-developer" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a semanticturkey-dev...@googlegroups.com.
Per altre opzioni visita https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages