I have a work around for slow or sometimes unavailable SPARQL end points: I use a caching layer on my query clients. For the key I use the original SPARQL query and the key values are the results in either JSON form or language native form. Usually I use JSON stored in Postgres.
This makes unit tests possible and generally speeds up interactive development of systems where linked data sources are used.
I agree, which is why I invited Ruben Verborgh the main man behind it to give a talk yesterday in Geneva during a PhD course on practically using sem web tech for bio research.
Linkeddata fragments is a nice new tech sitting between dumb data dumps on ftp and smart but expensive sparql endpoints. To be used when bandwidth from server to client is cheaper than ram on sparql server.
2 comments
[ 4.1 ms ] story [ 18.2 ms ] threadI have a work around for slow or sometimes unavailable SPARQL end points: I use a caching layer on my query clients. For the key I use the original SPARQL query and the key values are the results in either JSON form or language native form. Usually I use JSON stored in Postgres.
This makes unit tests possible and generally speeds up interactive development of systems where linked data sources are used.
Linkeddata fragments is a nice new tech sitting between dumb data dumps on ftp and smart but expensive sparql endpoints. To be used when bandwidth from server to client is cheaper than ram on sparql server.