Just a little usage example to illustrate Stian's point:
public class Main {
public static void main(String... args) {
Graph g = new SparqlGraph("http://dbpedia.org/sparql";);
Iterator<Triple> iter = g.filter(new Iri("
http://dbpedia.org/ontology/Planet";),
new Iri("http://www.w3.org/1999/02/22-rdf-syntax-ns#type";),
null);
while (iter.hasNext()) {
System.out.println(iter.next().getObject());
}
}
}
I think with Stian's version using streams the above could be shorter and
nicer. But the important part is that the above allows to use dbpedia as a
graph without worrying about sparql.
Cheers,
Reto
On Fri, Mar 20, 2015 at 4:16 PM, Stian Soiland-Reyes <[email protected]>
wrote:
> I think a query interface as you say is orthogonal to Reto's
> impl.sparql module - which is trying to be an implementation of RDF
> Commons that is backed only by a remote SPARQL endpoint. Thus it
> touches on important edges like streaming and blank node identities.
>
> It's not a SPARQL endpoint backed by RDF Commons! :-)
>
>
>
> On 20 March 2015 at 10:58, Sergio Fernández <[email protected]> wrote:
> > Hi Reto,
> >
> > yes, that was a deliberated decision on early phases. I'd need to look it
> > up, I do not remember the concrete issue.
> >
> > Just going a bit deeper into the topic, in querying we are talking not
> only
> > about providing native support to query Graph instance, but also to
> provide
> > common interfaces to interact with the results.
> >
> > The idea was to keep the focus on RDF 1.1 concepts before moving to
> query.
> > Personally I'd prefer to keep that scope for the first incubator release,
> > and then start to open discussions about such kind of threads. But of
> course
> > we can vote to change that approach.
> >
> > Cheers,
> >
> >
> >
> > On 17/03/15 11:05, Reto Gmür wrote:
> >>
> >> Hi Sergio,
> >>
> >> I'm not sure which deliberate decision you are referring to, is it Issue
> >> #35 in Github?
> >>
> >> Anyway, the impl.sparql code is not about extending the API to allow
> >> running queries on a graph, in fact the API isn't extended at all. It's
> an
> >> implementation of the API which is backed by a SPARQL endpoint. Very
> often
> >> the triple store doesn't run in the same VM as the client and so it is
> >> necessary that implementation of the API speak to a remote triple store.
> >> This can use some proprietary protocols or standard SPARQL, this is an
> >> implementation for SPARQL and can thus be used against any SPARQL
> >> endpoint.
> >>
> >> Cheers,
> >> Reto
> >>
> >>
> >>
> >>
> >> On Tue, Mar 17, 2015 at 7:41 AM, Sergio Fernández <[email protected]>
> >> wrote:
> >>
> >>> Hi Reto,
> >>>
> >>> thanks for updating us with the status from Clerezza.
> >>>
> >>> In the current Commons RDF API we delivery skipped querying for the
> early
> >>> versions.
> >>>
> >>> Although I'd prefer to keep this approach in the initial steps at ASF
> (I
> >>> hope we can import the code soon...), that's for sure one of the next
> >>> points to discuss in the project, where all that experience is
> valuable.
> >>>
> >>> Cheers,
> >>>
> >>> On 16/03/15 13:02, Reto Gmür wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> With the new repository the clerezza rdf commons previously in the
> >>>> commons
> >>>> sandbox are now at:
> >>>>
> >>>> https://git-wip-us.apache.org/repos/asf/clerezza-rdf-core.git
> >>>>
> >>>> I will compare that code with the current status of the code in the
> >>>> incubating rdf-commons project in a later mail.
> >>>>
> >>>> Now I would like to point to your attention a big step forward towards
> >>>> CLEREZZA-856. The impl.sparql modules provide an implementation of the
> >>>> API
> >>>> on top of a SPARQL endpoint. Currently it only supports read access.
> For
> >>>> usage example see the tests in
> >>>> /src/test/java/org/apache/commons/rdf/impl/sparql (
> >>>> https://git-wip-us.apache.org/repos/asf?p=clerezza-rdf-core.
> >>>> git;a=tree;f=impl.sparql/src/test/java/org/apache/commons/
> >>>> rdf/impl/sparql;h=cb9c98bcf427452392e74cd162c08ab308359c13;hb=HEAD
> >>>> )
> >>>>
> >>>> The hard part was supporting BlankNodes. The current implementation
> >>>> handles
> >>>> them correctly even in tricky situations, however the current code is
> >>>> not
> >>>> optimized for performance yet. As soon as BlankNodes are involved many
> >>>> queries have to be sent to the backend. I'm sure some SPARQL wizard
> >>>> could
> >>>> help making things more efficient.
> >>>>
> >>>> Since SPARQL is the only standardized methods to query RDF data, I
> think
> >>>> being able to façade an RDF Graph accessible via SPARQL is an
> important
> >>>> usecase for an RDF API, so it would be good to also have an SPARQL
> >>>> backed
> >>>> implementation of the API proposal in the incubating commons-rdf
> >>>> repository.
> >>>>
> >>>> Cheers,
> >>>> Reto
> >>>>
> >>>>
> >>> --
> >>> Sergio Fernández
> >>> Partner Technology Manager
> >>> Redlink GmbH
> >>> m: +43 660 2747 925
> >>> e: [email protected]
> >>> w: http://redlink.co
> >>>
> >>
> >
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: [email protected]
> > w: http://redlink.co
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
