Clojurians Log v2

hey 😛

yo

So based on the feedback by @rickmoynihan I’ll be releasing a new version of YeSPARQL that is able to consume the ResultSet iteratively

Awesome! :simple_smile:

We’re still debating some future ideas, for example doing type conversion to native Clojure data structures, but that’ll be work for another version :simple_smile:

I probably won't get much time to try YeSPARQL this week

Me neither, I have some other stuff to do as well :simple_smile: but it’s probably good to sleep on it some more as well!

It’s fun, first Clojure library that has some attention :simple_smile:

(that I wrote)

https://github.com/joelkuiper/yesparql#results-processing

:simple_smile:

Glad you're enjoying it - its great to see some activity other Grafter in the clojure RDF space

I definitely think we should try and work together / as much as we can -- to create a healthy eco-system

maybe we need the ring of clojure RDF :simple_smile:

yeah it’s silly, I never really liked Semantic Web. But I’m working in the biomedical space, and I use of a lot ontologies (like UMLS, Human Phenotype, Cancer Ontology), mostly for annotation of database resources with OpenAnnotations … and I kinda enjoy it. There are so many things that seem to have been reinvented outside Semantic Web as well a couple of times, but the whole thing has a nice holistic feel to it

Have you seen this btw: http://commonsrdf.incubator.apache.org/

yeah, we could discuss what that would look like. Stupid thing is that there are two competing libraries (sesame and jena), with different tradeoffs

Its a project to help enable basic interop between sesame/jena

hmm, no that sounds very useful

is it a bit mature? We might piggy back on to off that for YeSPARQL/Grafter

I don't think they support it yet -- but I think sesame 4 and the next JENA will

awesome, Jena just released 3.0 (after a long while) … so it might take some time 😛

well I was thinking a minimal clojure wrapper over it would be nice

JENA 3 might support it - not sure

Over CommonsRDF?

I saw no mention in the release notes, might have missed it … although they’re not very good at documenting some times 😛

maybe not then

but it has both JENA and Sesame contributors working together on it

(I think)

ok going to go quiet for a while - I need to do some real work :simple_smile:

Right, so writing a little library that takes Common RDF representations and maps it to Clojure data structures would solve the Jena/Sesame interop nicely I think

same here 😉

I think thats a long term thing -- right now our best hope of doing that is probably to use some common protocols across both jena/sesame core types (and also the commons-rdf ones)

not sure on the details though -- might not achieve much in practice...

well we could re-use that library across YeSPARQL and Grafter

that’s a win I’d say

and if Jena, Sesame switch to CommonsRDF it will only make it easier I guess

[announcement] YeSPARQL 0.1.5 https://github.com/joelkuiper/yesparql, see https://github.com/joelkuiper/yesparql#results-processing for the most notable change

@rickmoynihan: Thanks for the link to Apache Commons RDF. First I’d heard of it.

n/p @jamesaoverton -- not really sure how useful it is yet though - as neither sesame or jena appear to actually implement those interfaces yet ... more something for the future :simple_smile:

How would grafter parse a http://www.w3.org/1999/02/22-rdf-syntax-ns#langString to a Clojure object?

something like {:value … :lang …} ?

That’s the shape used in EDN-LD: https://github.com/ontodev/edn-ld/blob/master/test/edn_ld/core_test.clj#L74

… which is intentionally similar to JSON-LD.

hmm, may stick to that then

what would you prefer to return as an URI, a java.net.URI or just a string?

I work with OWL 2 a lot, which uses IRIs. The OWLAPI has its own IRI class: http://owlapi.sourceforge.net/javadoc/org/semanticweb/owlapi/model/IRI.html

Instead of choosing between java.net.URI and that IRI class, I just stick with strings.

So, that’s the tradeoff I’ve chosen.

hmm, makes sense

I’ll be interested to hear how Grafter does it.

This will sounds really stupid … but how do you get the Quads from a Jena Model? I’m iterating over Statements, but I have no idea how to get the graph names …

I think that com.hp.hpl.jena.rdf.model.Model is just a set of triples. So you’ll also need the name of graph that the model represents to make a quad.

To deal with multiple graphs, you use com.hp.hpl.jena.query.Dataset which contains a bunch of Models.

And remember that Jena has two main interfaces for triples: Model and Graph. Likewise there are two main interfaces for quads: Dataset and DatasetGraph. It’s easy to convert between the pairs of interfaces. DatasetGraph explicitly has quads.

right but if I do an execConstruct on a QueryExecution I get a Model, can I get the graphs from that?

Or will it do something clever and return something else when the query has Quads? (like a Dataset?)

Does this help? https://jena.apache.org/documentation/query/construct-quad.html

I don’t see QueryExecution.execConstructDataset() in the JavaDocs...

no, funnily neither execConstructQuads

it’s weird though right, if I run execConstruct I would persume I’d be able to get quads somehow

Do those methods run? Are they just undocumented?

unsure

hang on, I’ll try

if execConstructDataset works I assume I can get quads from that somehow

The only thing I’ve done in the past is run UpdateProcessor.execute() on a DatasetGraph, then grab the stuff I want from the modified DatasetGraph. It works fine, but I don’t think it’s what you want.

hmm looks like they’re not in 3.0

seems like a recent addition

there’s getDataset on QueryExecution, but I’m not sure how that works

My guess would be that it gets you back the Dataset that you specified in QueryExecutionFactory.create().

right, so that won’t work for remote SPARQL endpoints

so no way of getting quads from a SPARQL construct in Jena 3.0 😛

https://stackoverflow.com/questions/32234268/quads-from-a-construct-query-in-jena

Initial try of getting type conversion to work in YeSPARQL

https://github.com/joelkuiper/yesparql/blob/feature/type-conversion/src/yesparql/sparql.clj#L110-L174

unfortunately no quads 😉

can always just use a SELECT

sure, but that’s kinda hacky 😛

seems like it’s being worked on, just a matter of waiting I guess