Repository navigation
Stringly-typed RDF representation #16
Description
Activity
hello,
you can find a easy-to-use API rest interface for communicate to RSP engines here [1].
The specific version for the C-SPARQL engine is [2], while in [3] there is a pointer to the paper.I hope I had help you out.
[1] https://github.com/streamreasoning/rsp-services
[2] https://github.com/streamreasoning/rsp-services-csparql
[3] http://dl.acm.org/citation.cfm?id=2874452Best Regards,
Riccardo Tommasini
M.D. Computer Science
PhD Student at Politecnico di Milano (Italy)
streamreasoning.orghttp://streamreasoning.orgSubmitted from an iPhone, I apologise for typos.
On 03 Mar 2016, at 11:43, pkapahnke <notifications@github.commailto:notifications@github.com> wrote:
The CSPARQL-engine API exposes RDF as tuple of strings, as for example in eu.larkc.csparql.common.RDFTuple.
For some applications, this is a unfortunate decision, because there is no straight-forward way to find out whether a string is a resource URI, blank node, literal or typed literal. In particular, I found no documentation about how blank node ids are generated, which made it hard to implement a regular expression for it.
Moreover, different kinds of queries return different kind of answers: RDF graphs, tables, boolean results etc. (CONSTUCT, SELECT, ASK...). It would be very helpful to have an actual meaningful representation for it.
Internally, CSPARQL-engine makes use of Jena, which would be perfect to also use for interfacing with CSPARQL-engine. Do you see any chance to have some improvements in this direction? Would be very much appreciated by a lot of developers, I guess.
(Btw.: Jena generates blank node ids using java.rmi.server.UID, at least for version 3.0.1, in case you face similar problems with identifying blank nodes).
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16.
The CSPARQL-engine API exposes RDF as tuple of strings, as for example in
eu.larkc.csparql.common.RDFTuple.For some applications, this is a unfortunate decision, because there is no straight-forward way to find out whether a string is a resource URI, blank node, literal or typed literal. In particular, I found no documentation about how blank node ids are generated, which made it hard to implement a regular expression for it.
Moreover, different kinds of queries return different kind of answers: RDF graphs, tables, boolean results etc. (CONSTUCT, SELECT, ASK...). It would be very helpful to have an actual meaningful representation for it.
Internally, CSPARQL-engine makes use of Jena, which would be perfect to also use for interfacing with CSPARQL-engine. Do you see any chance to have some improvements in this direction? Would be very much appreciated by a lot of developers, I guess.
(Btw.: Jena generates blank node ids using
java.rmi.server.UID, at least for version 3.0.1, in case you face similar problems with identifying blank nodes).