This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-08-26
Channels
- # admin-announcements (33)
- # beginners (41)
- # boot (97)
- # clojure (220)
- # clojure-berlin (3)
- # clojure-russia (31)
- # clojure-sg (3)
- # clojurebridge (2)
- # clojurescript (137)
- # clojutre (13)
- # core-matrix (10)
- # core-typed (1)
- # cursive (18)
- # datascript (1)
- # datomic (93)
- # devops (6)
- # editors (18)
- # emacs (1)
- # funcool (43)
- # hoplon (4)
- # immutant (6)
- # instaparse (3)
- # jobs (25)
- # ldnclj (14)
- # ldnproclodo (4)
- # off-topic (20)
- # om (21)
- # rdf (79)
- # re-frame (14)
- # reagent (12)
- # ring-swagger (18)
- # yada (52)
hey 😛
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!
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
I probably won't get much time to try YeSPARQL this week
Me neither, I have some other stuff to do as well but it’s probably good to sleep on it some more as well!
It’s fun, first Clojure library that has some attention
(that I wrote)
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
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
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
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 😛
Initial try of getting type conversion to work in YeSPARQL
unfortunately no quads 😉
sure, but that’s kinda hacky 😛
seems like it’s being worked on, just a matter of waiting I guess