Re: [w3c/rdf-tests] rdf-capable docker packages - scope for testing automation? (#48)

> On Jul 4, 2017, at 12:30 PM, Dan Brickley <notifications@github.com> wrote:
> 
> It seems a good number of RDF-oriented tools are now available via Docker. Has this community given thought to whether this could help with automated testing, and whether there are any additional community conventions that might be documented to make that easier?
> 
The RDFa Test Suite at http://rdfa.info/test-suite/ <http://rdfa.info/test-suite/> (broken right now, waiting for some rdflib.js help) took a similar approach to testing, where implementations would expose an endpoint which would take a URI ending with a query argument to identify the source test and be expected to generate a result, typically N-Triples, but could be Turtle, after which the test running would run a SPARQL query to check results. A similar strategy could be used to run tests by poking a docker image to do the same, and validate results, perhaps using a Travis-CI build matrix to run against a combination of docker images and test suites.
> My original reason for digging around was to see if this would make an easy way to quickly spin up an RDF-backed site (with sparql etc.) given a dataset. It seems that this is eminently doable but each package - although available via docker - has different conventions for loading data. For that, I don't know if there are any conventions emerging (e.g. https://www.w3.org/TR/ldp/ <https://www.w3.org/TR/ldp/> )? But in the case of a simple stateless RDF parser turning inputs into ntriples, maybe it wouldn't take quite so much work to encapsulate behind a common interface?
> 
I’m not sure LDP can handle this, as is, and would in any case require establishing some conventions for talking to an endpoint. For a SPARQL protocol test, this might work with and endpoint which published a SPARQL Service Description, but would still require a means of initializing the dataset.

The RDF Test CG would be a great place to drive a standardized way of doing such things, at least for the purpose of responding to a test runner. The broader goal of spinning up standardized endpoints for transforming RDF serializations and querying some specified dataset is beyond the CG charter, but work might start there and lead to something else.

Gregg
> An incomplete list of RDF tools I found with a little searching on hub.docker.com. I didn't look very deeply or distinguish re-packagings from those dockerized by their maintainers.
> 
> https://hub.docker.com/r/cnstntn/sem2ls/ <https://hub.docker.com/r/cnstntn/sem2ls/> (raptor for parsers, roqet for sparql, etc.)
> https://hub.docker.com/r/stain/jena/ <https://hub.docker.com/r/stain/jena/> (apache jena)
> https://hub.docker.com/r/inutano/rdf-tools/ <https://hub.docker.com/r/inutano/rdf-tools/> (any23, parsers)
> https://hub.docker.com/r/ioinformatics/neo4j-rdf/ <https://hub.docker.com/r/ioinformatics/neo4j-rdf/> (neo4j rdf)
> https://hub.docker.com/r/silviodc/cliopatria/ <https://hub.docker.com/r/silviodc/cliopatria/> (swi-prolog cliopatria incl. parsers, sparql http://cliopatria.swi-prolog.org/help/whitepaper.html <http://cliopatria.swi-prolog.org/help/whitepaper.html> )
> https://hub.docker.com/r/subotic/openrdf-sesame/ <https://hub.docker.com/r/subotic/openrdf-sesame/> (sesame - parsers, sparql etc)
> https://hub.docker.com/r/eccenca/adhs/ <https://hub.docker.com/r/eccenca/adhs/> (rdflib-based sparql endpoint)
> https://hub.docker.com/r/lyrasis/blazegraph/ <https://hub.docker.com/r/lyrasis/blazegraph/> (blazegraph db - parsers, sparql etc.)
> https://hub.docker.com/r/nice/ld-docker-stardog/ <https://hub.docker.com/r/nice/ld-docker-stardog/> (stardog db, sparql, parsers etc)
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub <https://github.com/w3c/rdf-tests/issues/48>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC02N382i2JXD211j4pZl1p7PjGGqtCks5sKpLrgaJpZM4ONo3f>.
>