Created
March 26, 2015 11:29
-
-
Save stain/836e8c8ccc6396e1ea55 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Delivered-To: stian@s11.no | |
| Received: by 10.28.194.7 with SMTP id s7csp284007wmf; | |
| Thu, 26 Mar 2015 01:57:09 -0700 (PDT) | |
| X-Received: by 10.70.92.132 with SMTP id cm4mr24666356pdb.18.1427360228839; | |
| Thu, 26 Mar 2015 01:57:08 -0700 (PDT) | |
| Return-Path: <> | |
| Received: from mail.apache.org (hermes.apache.org. [140.211.11.3]) | |
| by mx.google.com with SMTP id j12si7469396pdm.58.2015.03.26.01.57.08 | |
| for <stian@s11.no>; | |
| Thu, 26 Mar 2015 01:57:08 -0700 (PDT) | |
| Received-SPF: none (google.com: mail.apache.org does not designate permitted sender hosts) client-ip=140.211.11.3; | |
| Authentication-Results: mx.google.com; | |
| spf=none (google.com: mail.apache.org does not designate permitted sender hosts) smtp.mail= | |
| Message-Id: <5513c9e4.2c2d460a.35fe.5ba7SMTPIN_ADDED_MISSING@mx.google.com> | |
| Received: (qmail 10779 invoked by uid 500); 26 Mar 2015 08:57:07 -0000 | |
| Delivered-To: apmail-stain@apache.org | |
| Received: (qmail 10776 invoked for bounce); 26 Mar 2015 08:57:07 -0000 | |
| Date: 26 Mar 2015 08:57:07 -0000 | |
| From: MAILER-DAEMON@apache.org | |
| To: stain@apache.org | |
| Subject: failure notice | |
| Hi. This is the qmail-send program at apache.org. | |
| I'm afraid I wasn't able to deliver your message to the following addresses. | |
| This is a permanent error; I've given up. Sorry it didn't work out. | |
| <dev@commonsrdf.incubator.apache.org>: | |
| 192.87.106.230 failed after I sent the message. | |
| Remote host said: 552 spam score (7.8) exceeded threshold (HTML_MESSAGE,RCVD_IN_BRBL_LASTEXT,RCVD_IN_XBL | |
| --- Below this line is a copy of the message. | |
| Return-Path: <stain@apache.org> | |
| Received: (qmail 8875 invoked by uid 99); 26 Mar 2015 08:55:25 -0000 | |
| Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) | |
| by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Mar 2015 08:55:25 +0000 | |
| Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) | |
| by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 9FF311A0466 | |
| for <dev@commonsrdf.incubator.apache.org>; Thu, 26 Mar 2015 08:55:24 +0000 (UTC) | |
| Received: by wibbg6 with SMTP id bg6so55566899wib.0 | |
| for <dev@commonsrdf.incubator.apache.org>; Thu, 26 Mar 2015 01:55:23 -0700 (PDT) | |
| X-Gm-Message-State: ALoCoQnh2B0H7VJ+wiEq8YCQSLH71ncpU6yQ9Ol2NnOy+OJSBob1/PCroERIANknl++A2PzAvsnx | |
| MIME-Version: 1.0 | |
| X-Received: by 10.194.220.7 with SMTP id ps7mr26719845wjc.84.1427360123183; | |
| Thu, 26 Mar 2015 01:55:23 -0700 (PDT) | |
| Received: by 10.28.29.8 with HTTP; Thu, 26 Mar 2015 01:55:23 -0700 (PDT) | |
| X-Originating-IP: [92.40.249.67] | |
| Received: by 10.28.29.8 with HTTP; Thu, 26 Mar 2015 01:55:23 -0700 (PDT) | |
| In-Reply-To: <CAGYFOCS+5YiTK9MS114Pj8kDQ-ZQ9ShWvn4DGR4H9RWaOceB4g@mail.gmail.com> | |
| References: <CAMBJEmWC-dV6p1HZ7cvkKJtE0jks-EZJJedK92KG49SnX-oTAA@mail.gmail.com> | |
| <CAMBJEmVVsO+D6oqMr6+k=MFWSs4Krv2W23wEbzb7hErQbiQ16g@mail.gmail.com> | |
| <CAGYFOCS+5YiTK9MS114Pj8kDQ-ZQ9ShWvn4DGR4H9RWaOceB4g@mail.gmail.com> | |
| Date: Thu, 26 Mar 2015 08:55:23 +0000 | |
| Message-ID: <CAMBJEmVLfB2_VV20d4WMZS3AGd4ai-FKAXX4+E+2OqXr6D=skQ@mail.gmail.com> | |
| Subject: Re: Hashcode definition | |
| From: Stian Soiland-Reyes <stain@apache.org> | |
| To: dev <dev@commonsrdf.incubator.apache.org> | |
| Content-Type: multipart/alternative; boundary=001a11c1b4241bfd0d05122d2dd0 | |
| --001a11c1b4241bfd0d05122d2dd0 | |
| Content-Type: text/plain; charset=UTF-8 | |
| Content-Transfer-Encoding: quoted-printable | |
| Likewise I would also like the IRI hashcode to be equal to its iriString | |
| hashcode, so that a similar optimization is possible for the datatype. | |
| On 26 Mar 2015 01:52, "Peter Ansell" <ansell.peter@gmail.com> wrote: | |
| > Hi Stian, | |
| > | |
| > We would be best to not use Optional in the hashCode definition, | |
| > incase people are actually storing "null" or another sentinel value | |
| > internally and only adding Optional on to satisfy our API. Otherwise | |
| > they will need to refer to Optional each time to get the hashCode, or | |
| > if they are using immutable objects, they would need to refer to it | |
| > for each object creation, both of which would be sub-optimal if they | |
| > are trying to optimise that part of their system. | |
| > | |
| > Cheers, | |
| > | |
| > Peter | |
| > | |
| > | |
| > On 26 March 2015 at 12:21, Stian Soiland-Reyes <stain@apache.org> wrote: | |
| > > Why multiply with 5 in the IRI ? Just to spread it from a hash of the I= | |
| RI | |
| > > and its String? | |
| > > | |
| > > It means the "hashcode of the data type" in Literal can be slightly | |
| > > ambiguous. Perhaps "hashcode of the #getDataType() IRI" ? It also hamme= | |
| rs | |
| > > in through getDataType that every Literal has a datatype, e.g. it is | |
| > always | |
| > > added to the hash. | |
| > > | |
| > > BTW, hashcode of the Optional language is conveniently compliant with | |
| > "plus | |
| > > hash code of language if present", so no similar ambiguity there. | |
| > > | |
| > > | |
| > https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html#hashCod= | |
| e-- | |
| > > On 24 Mar 2015 12:25, "Reto Gm=C3=BCr" <reto@apache.org> wrote: | |
| > > | |
| > > On Mon, Mar 23, 2015 at 12:04 PM, Andy Seaborne <andy@apache.org> wrote= | |
| : | |
| > > | |
| > >> On 23/03/15 10:25, Reto Gm=C3=BCr wrote: | |
| > >> | |
| > >>> Right now the API on Github says nothing about the identity and hasco= | |
| de | |
| > > of | |
| > >>> any term. In order to have interoperable it is essential to define th= | |
| e | |
| > >>> value of hashcode and the identity conditions for the rdf-terms which | |
| > are | |
| > >>> not locally scoped, i.e. for IRIs and Literals. | |
| > >>> | |
| > >> | |
| > >> +1 | |
| > >> | |
| > >> | |
| > >>> I suggest to take the definitions from the clerezza rdf commons. | |
| > >>> | |
| > >> | |
| > >> Absent active JIRA at the moment, could you email here please? | |
| > >> | |
| > >> Given Peter is spending time on his implementation, this might be quit= | |
| e | |
| > >> useful to him. | |
| > >> | |
| > >> Sure. | |
| > > | |
| > > Literal: the hash code of the lexical form plus the hash code of the | |
| > > datatype plus if the literal has a language the hash code of the langua= | |
| ge | |
| > > | |
| > > | |
| > https://git-wip-us.apache.org/repos/asf?p=3Dclerezza-rdf-core.git;a=3Dblo= | |
| b;f=3Dapi/src/main/java/org/apache/commons/rdf/Literal.java;h=3Dcf5e1eea2d8= | |
| 48a57e4e338a3d208f127103d39a4;hb=3DHEAD | |
| > > | |
| > > And the IRI: 5 + the hashcode of the string | |
| > > | |
| > > | |
| > https://git-wip-us.apache.org/repos/asf?p=3Dclerezza-rdf-core.git;a=3Dblo= | |
| b;f=3Dapi/src/main/java/org/apache/commons/rdf/Iri.java;h=3De1ef0f7d21a3cb6= | |
| 68b4a3b2f2aae7e2f642b68dd;hb=3DHEAD | |
| > > | |
| > > Reto | |
| > > | |
| > > Andy | |
| > >> | |
| > >> | |
| > >> | |
| > >>> Reto | |
| > >>> | |
| > >>> On Mon, Mar 23, 2015 at 10:18 AM, Stian Soiland-Reyes < | |
| > stain@apache.org> | |
| > >>> wrote: | |
| > >>> | |
| > >>> OK - I can see on settling BlankNode equality can take some more tim= | |
| e | |
| > >>>> (also considering the SPARQL example). | |
| > >>>> | |
| > >>>> So then we must keep the "internalIdentifier" and the abstract conce= | |
| pt | |
| > >>>> of the "local scope" for the next release. | |
| > >>>> | |
| > >>>> In which case this one should also be applied: | |
| > >>>> | |
| > >>>> https://github.com/commons-rdf/commons-rdf/pull/48/files | |
| > >>>> and perhaps: | |
| > >>>> https://github.com/commons-rdf/commons-rdf/pull/61/files | |
| > >>>> | |
| > >>>> | |
| > >>>> | |
| > >>>> I would then need to fix simple GraphImpl.add() to clone and change | |
| > >>>> the local scope of the BlankNodes: | |
| > >>>> .. as otherwise it would wrongly merge graph1.b1 and graph2.b1 (in | |
| > >>>> both having the same internalIdentifier and the abstract Local Scope | |
| > >>>> of being in the same Graph). This can happen if doing say a copy fro= | |
| m | |
| > >>>> one graph to another. | |
| > >>>> | |
| > >>>> Raised and detailed in | |
| > >>>> https://github.com/commons-rdf/commons-rdf/issues/66 | |
| > >>>> .. adding this to the tests sounds crucial, and would help us later | |
| > >>>> when sorting this. | |
| > >>>> | |
| > >>>> | |
| > >>>> This is in no way a complete resolution. (New bugs would arise, e.g. | |
| > >>>> you could add a triple with a BlankNode and then not remove it | |
| > >>>> afterwards with the same arguments). | |
| > >>>> | |
| > >>>> | |
| > >>>> | |
| > >>>> | |
| > >>>> | |
| > >>>> On 22 March 2015 at 21:00, Peter Ansell <ansell.peter@gmail.com> | |
| > wrote: | |
| > >>>> | |
| > >>>>> +1 | |
| > >>>>> | |
| > >>>>> Although it is not urgent to release a 1.0 version, it is urgent to | |
| > >>>>> release (and keep releasing often) what we have changed since 0.0.2 | |
| > so | |
| > >>>>> we can start experimenting with it, particularly since I have start= | |
| ed | |
| > >>>>> more intently on Sesame 4 in the last few weeks. Stians pull reques= | |
| ts | |
| > >>>>> to change the BNode situation could wait until after 0.0.3 is | |
| > >>>>> released, at this point. | |
| > >>>>> | |
| > >>>>> Cheers, | |
| > >>>>> | |
| > >>>>> Peter | |
| > >>>>> | |
| > >>>>> On 21 March 2015 at 22:37, Andy Seaborne <andy@apache.org> wrote: | |
| > >>>>> | |
| > >>>>>> I agree with Sergio that releasing something is important. | |
| > >>>>>> | |
| > >>>>>> We need to release, then independent groups can start to build on | |
| > it. | |
| > >>>>>> We | |
| > >>>>>> have grounded requirements and a wider community. | |
| > >>>>>> | |
| > >>>>>> Andy | |
| > >>>>>> | |
| > >>>>>> | |
| > >>>>>> On 21/03/15 09:10, Reto Gm=C3=BCr wrote: | |
| > >>>>>> | |
| > >>>>>>> | |
| > >>>>>>> Hi Sergio, | |
| > >>>>>>> | |
| > >>>>>>> I don't see where an urgent agenda comes from. Several RDF APIs a= | |
| re | |
| > >>>>>>> | |
| > >>>>>> there | |
| > >>>> | |
| > >>>>> so a new API essentially needs to be better rather than done with | |
| > >>>>>>> | |
| > >>>>>> urgency. | |
| > >>>> | |
| > >>>>> | |
| > >>>>>>> The SPARQL implementation is less something that need to be part = | |
| of | |
| > >>>>>>> the | |
| > >>>>>>> first release but something that helps validating the API proposa= | |
| l. | |
| > > We | |
| > >>>>>>> should validate our API against many possible usecases and then | |
| > > discus | |
| > >>>>>>> which are more important to support. In my opinion for an RDF API | |
| > it | |
| > >>>>>>> is | |
| > >>>>>>> more important that it can be used with remote repositories over | |
| > >>>>>>> | |
| > >>>>>> standard | |
| > >>>> | |
| > >>>>> protocols than support for hadoop style processing across many | |
| > machines | |
| > >>>>>>> [1], but maybe we can support both usecases. | |
| > >>>>>>> | |
| > >>>>>>> In any case I think its good to have prototypical implementation = | |
| of | |
| > >>>>>>> usecases to see what API features are needed and which are | |
| > >>>>>>> | |
| > >>>>>> problematic. So | |
| > >>>> | |
| > >>>>> I would encourage to write prototype usecases where a hadoop style | |
| > >>>>>>> processing shows the need for exposed blank node ID or a prototyp= | |
| e | |
| > >>>>>>> | |
| > >>>>>> showing | |
| > >>>> | |
| > >>>>> that that IRI is better an interface than a class, etc. | |
| > >>>>>>> | |
| > >>>>>>> At the end we need to decide on the API features based on the | |
| > > usecases | |
| > >>>>>>> they | |
| > >>>>>>> are required by respectively compatible with. But it's hard to se= | |
| e | |
| > > the | |
| > >>>>>>> requirements without prototypical code. | |
| > >>>>>>> | |
| > >>>>>>> Cheers, | |
| > >>>>>>> Reto | |
| > >>>>>>> | |
| > >>>>>>> 1. | |
| > >>>>>>> | |
| > >>>>>>> https://github.com/commons-rdf/commons-rdf/pull/48# | |
| > >>>> issuecomment-72689214 | |
| > >>>> | |
| > >>>>> | |
| > >>>>>>> On Fri, Mar 20, 2015 at 8:30 PM, Sergio Fern=C3=A1ndez < | |
| > wikier@apache.org> | |
| > >>>>>>> wrote: | |
| > >>>>>>> | |
| > >>>>>>> I perfectly understand what you target. But still, FMPOV still o= | |
| ut | |
| > > of | |
| > >>>>>>>> | |
| > >>>>>>> our | |
| > >>>> | |
| > >>>>> urgent agenda. Not because it is not interesting, just because more | |
| > >>>>>>>> urgent | |
| > >>>>>>>> things to deal with. I think the most important think is to get | |
| > >>>>>>>> | |
| > >>>>>>> running | |
| > >>>> | |
| > >>>>> with what we have, and get a release out. But, as I said, we can | |
| > >>>>>>>> | |
| > >>>>>>> discuss | |
| > >>>> | |
| > >>>>> it. | |
| > >>>>>>>> | |
| > >>>>>>>> | |
| > >>>>>>>> On 20/03/15 19:10, Reto Gm=C3=BCr wrote: | |
| > >>>>>>>> | |
| > >>>>>>>> Just a little usage example to illustrate Stian's point: | |
| > >>>>>>>>> | |
| > >>>>>>>>> public class Main { | |
| > >>>>>>>>> public static void main(String... args) { | |
| > >>>>>>>>> Graph g =3D new SparqlGraph("http://dbpedia.org/spar= | |
| ql | |
| > "); | |
| > >>>>>>>>> Iterator<Triple> iter =3D 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 < | |
| > >>>>>>>>> | |
| > >>>>>>>> stain@apache.org> | |
| > >>>> | |
| > >>>>> wrote: | |
| > >>>>>>>>> | |
| > >>>>>>>>> I think a query interface as you say is orthogonal to Reto's | |
| > >>>>>>>>> | |
| > >>>>>>>>>> | |
| > >>>>>>>>>> impl.sparql module - which is trying to be an implementation o= | |
| f | |
| > > 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=C3=A1ndez <wikier@apach= | |
| e.org> | |
| > >>>>>>>>>> | |
| > >>>>>>>>> wrote: | |
| > >>>> | |
| > >>>>> | |
| > >>>>>>>>>> Hi Reto, | |
| > >>>>>>>>>>> | |
| > >>>>>>>>>>> yes, that was a deliberated decision on early phases. I'd nee= | |
| d | |
| > 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=C3=BCr 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 endpoin= | |
| t. | |
| > >>>>>>>>>>> | |
| > >>>>>>>>>> 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=C3=A1ndez < | |
| > >>>>>>>>>>>> | |
| > >>>>>>>>>>> wikier@apache.org> | |
| > >>>> | |
| > >>>>> 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=C3=BCr wrote: | |
| > >>>>>>>>>>>>> | |
| > >>>>>>>>>>>>> Hello, | |
| > >>>>>>>>>>>>> | |
| > >>>>>>>>>>>>>> | |
| > >>>>>>>>>>>>>> | |
| > >>>>>>>>>>>>>> With the new repository the clerezza rdf commons previousl= | |
| y | |
| > 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 co= | |
| de | |
| > > 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 re= | |
| ad | |
| > >>>>>>>>>>>>>> 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=3Dclerezza-rdf-c= | |
| ore | |
| > . | |
| > >>>>>>>>>>>>>> git;a=3Dtree;f=3Dimpl.sparql/src/test/java/org/apache/comm= | |
| ons/ | |
| > >>>>>>>>>>>>>> | |
| > >>>>>>>>>>>>>> rdf/impl/sparql;h=3Dcb9c98bcf427452392e74cd162c08a | |
| > >>>> b308359c13;hb=3DHEAD | |
| > >>>> | |
| > >>>>> ) | |
| > >>>>>>>>>>>>>> | |
| > >>>>>>>>>>>>>> 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 SPAR= | |
| QL | |
| > >>>>>>>>>>>>>> | |
| > >>>>>>>>>>>>> wizard | |
| > >>>> | |
| > >>>>> could | |
| > >>>>>>>>>>>>>> help making things more efficient. | |
| > >>>>>>>>>>>>>> | |
| > >>>>>>>>>>>>>> Since SPARQL is the only standardized methods to query RDF | |
| > >>>>>>>>>>>>>> | |
| > >>>>>>>>>>>>> data, I | |
| > >>>> | |
| > >>>>> | |
| > >>>>>>>>>>>>>> think | |
| > >>>>>>>>>>>>> | |
| > >>>>>>>>>>>> | |
| > >>>>>>>>>> | |
| > >>>>>>>>>> being able to fa=C3=A7ade 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=C3=A1ndez | |
| > >>>>>>>>>>>>> Partner Technology Manager | |
| > >>>>>>>>>>>>> Redlink GmbH | |
| > >>>>>>>>>>>>> m: +43 660 2747 925 | |
| > >>>>>>>>>>>>> e: sergio.fernandez@redlink.co | |
| > >>>>>>>>>>>>> w: http://redlink.co | |
| > >>>>>>>>>>>>> | |
| > >>>>>>>>>>>>> | |
| > >>>>>>>>>>>>> | |
| > >>>>>>>>>>>> -- | |
| > >>>>>>>>>>> Sergio Fern=C3=A1ndez | |
| > >>>>>>>>>>> Partner Technology Manager | |
| > >>>>>>>>>>> Redlink GmbH | |
| > >>>>>>>>>>> m: +43 660 2747 925 | |
| > >>>>>>>>>>> e: sergio.fernandez@redlink.co | |
| > >>>>>>>>>>> w: http://redlink.co | |
| > >>>>>>>>>>> | |
| > >>>>>>>>>>> | |
| > >>>>>>>>>> | |
| > >>>>>>>>>> | |
| > >>>>>>>>>> -- | |
| > >>>>>>>>>> Stian Soiland-Reyes | |
| > >>>>>>>>>> Apache Taverna (incubating), Apache Commons RDF (incubating) | |
| > >>>>>>>>>> http://orcid.org/0000-0001-9842-9718 | |
| > >>>>>>>>>> | |
| > >>>>>>>>>> | |
| > >>>>>>>>>> | |
| > >>>>>>>>> -- | |
| > >>>>>>>> Sergio Fern=C3=A1ndez | |
| > >>>>>>>> Partner Technology Manager | |
| > >>>>>>>> Redlink GmbH | |
| > >>>>>>>> m: +43 660 2747 925 | |
| > >>>>>>>> e: sergio.fernandez@redlink.co | |
| > >>>>>>>> w: http://redlink.co | |
| > >>>>>>>> | |
| > >>>>>>>> | |
| > >>>>>>> | |
| > >>>>>> | |
| > >>>> | |
| > >>>> | |
| > >>>> -- | |
| > >>>> Stian Soiland-Reyes | |
| > >>>> Apache Taverna (incubating), Apache Commons RDF (incubating) | |
| > >>>> http://orcid.org/0000-0001-9842-9718 | |
| > >>>> | |
| > >>>> | |
| > >>> | |
| > >> | |
| > | |
| --001a11c1b4241bfd0d05122d2dd0 | |
| Content-Type: text/html; charset=UTF-8 | |
| Content-Transfer-Encoding: quoted-printable | |
| <p dir=3D"ltr">Likewise I would also like the IRI hashcode to be equal to i= | |
| ts iriString hashcode, so that a similar optimization is possible for the d= | |
| atatype.</p> | |
| <div class=3D"gmail_quote">On 26 Mar 2015 01:52, "Peter Ansell" &= | |
| lt;<a href=3D"mailto:ansell.peter@gmail.com">ansell.peter@gmail.com</a>>= | |
| wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"= | |
| margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Stian,<br= | |
| > | |
| <br> | |
| We would be best to not use Optional in the hashCode definition,<br> | |
| incase people are actually storing "null" or another sentinel val= | |
| ue<br> | |
| internally and only adding Optional on to satisfy our API. Otherwise<br> | |
| they will need to refer to Optional each time to get the hashCode, or<br> | |
| if they are using immutable objects, they would need to refer to it<br> | |
| for each object creation, both of which would be sub-optimal if they<br> | |
| are trying to optimise that part of their system.<br> | |
| <br> | |
| Cheers,<br> | |
| <br> | |
| Peter<br> | |
| <br> | |
| <br> | |
| On 26 March 2015 at 12:21, Stian Soiland-Reyes <<a href=3D"mailto:stain@= | |
| apache.org">stain@apache.org</a>> wrote:<br> | |
| > Why multiply with 5 in the IRI ? Just to spread it from a hash of the = | |
| IRI<br> | |
| > and its String?<br> | |
| ><br> | |
| > It means the "hashcode of the data type" in Literal can be s= | |
| lightly<br> | |
| > ambiguous. Perhaps "hashcode of the #getDataType() IRI" ? It= | |
| also hammers<br> | |
| > in through getDataType that every Literal has a datatype, e.g. it is a= | |
| lways<br> | |
| > added to the hash.<br> | |
| ><br> | |
| > BTW, hashcode of the Optional language is conveniently compliant with = | |
| "plus<br> | |
| > hash code of language if present", so no similar ambiguity there.= | |
| <br> | |
| ><br> | |
| > <a href=3D"https://docs.oracle.com/javase/8/docs/api/java/util/Optiona= | |
| l.html#hashCode--" target=3D"_blank">https://docs.oracle.com/javase/8/docs/= | |
| api/java/util/Optional.html#hashCode--</a><br> | |
| > On 24 Mar 2015 12:25, "Reto Gm=C3=BCr" <<a href=3D"mailto= | |
| :reto@apache.org">reto@apache.org</a>> wrote:<br> | |
| ><br> | |
| > On Mon, Mar 23, 2015 at 12:04 PM, Andy Seaborne <<a href=3D"mailto:= | |
| andy@apache.org">andy@apache.org</a>> wrote:<br> | |
| ><br> | |
| >> On 23/03/15 10:25, Reto Gm=C3=BCr wrote:<br> | |
| >><br> | |
| >>> Right now the API on Github says nothing about the identity an= | |
| d hascode<br> | |
| > of<br> | |
| >>> any term. In order to have interoperable it is essential to de= | |
| fine the<br> | |
| >>> value of hashcode and the identity conditions for the rdf-term= | |
| s which are<br> | |
| >>> not locally scoped, i.e. for IRIs and Literals.<br> | |
| >>><br> | |
| >><br> | |
| >> +1<br> | |
| >><br> | |
| >><br> | |
| >>> I suggest to take the definitions from the clerezza rdf common= | |
| s.<br> | |
| >>><br> | |
| >><br> | |
| >> Absent active JIRA at the moment, could you email here please?<br> | |
| >><br> | |
| >> Given Peter is spending time on his implementation, this might be = | |
| quite<br> | |
| >> useful to him.<br> | |
| >><br> | |
| >> Sure.<br> | |
| ><br> | |
| > Literal: the hash code of the lexical form plus the hash code of the<b= | |
| r> | |
| > datatype plus if the literal has a language the hash code of the langu= | |
| age<br> | |
| ><br> | |
| > <a href=3D"https://git-wip-us.apache.org/repos/asf?p=3Dclerezza-rdf-co= | |
| re.git;a=3Dblob;f=3Dapi/src/main/java/org/apache/commons/rdf/Literal.java;h= | |
| =3Dcf5e1eea2d848a57e4e338a3d208f127103d39a4;hb=3DHEAD" target=3D"_blank">ht= | |
| tps://git-wip-us.apache.org/repos/asf?p=3Dclerezza-rdf-core.git;a=3Dblob;f= | |
| =3Dapi/src/main/java/org/apache/commons/rdf/Literal.java;h=3Dcf5e1eea2d848a= | |
| 57e4e338a3d208f127103d39a4;hb=3DHEAD</a><br> | |
| ><br> | |
| > And the IRI: 5 + the hashcode of the string<br> | |
| ><br> | |
| > <a href=3D"https://git-wip-us.apache.org/repos/asf?p=3Dclerezza-rdf-co= | |
| re.git;a=3Dblob;f=3Dapi/src/main/java/org/apache/commons/rdf/Iri.java;h=3De= | |
| 1ef0f7d21a3cb668b4a3b2f2aae7e2f642b68dd;hb=3DHEAD" target=3D"_blank">https:= | |
| //git-wip-us.apache.org/repos/asf?p=3Dclerezza-rdf-core.git;a=3Dblob;f=3Dap= | |
| i/src/main/java/org/apache/commons/rdf/Iri.java;h=3De1ef0f7d21a3cb668b4a3b2= | |
| f2aae7e2f642b68dd;hb=3DHEAD</a><br> | |
| ><br> | |
| > Reto<br> | |
| ><br> | |
| >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Andy<br> | |
| >><br> | |
| >><br> | |
| >><br> | |
| >>> Reto<br> | |
| >>><br> | |
| >>> On Mon, Mar 23, 2015 at 10:18 AM, Stian Soiland-Reyes <<a h= | |
| ref=3D"mailto:stain@apache.org">stain@apache.org</a>><br> | |
| >>> wrote:<br> | |
| >>><br> | |
| >>>=C2=A0 OK - I can see on settling BlankNode equality can take s= | |
| ome more time<br> | |
| >>>> (also considering the SPARQL example).<br> | |
| >>>><br> | |
| >>>> So then we must keep the "internalIdentifier" an= | |
| d the abstract concept<br> | |
| >>>> of the "local scope" for the next release.<br> | |
| >>>><br> | |
| >>>> In which case this one should also be applied:<br> | |
| >>>><br> | |
| >>>> <a href=3D"https://github.com/commons-rdf/commons-rdf/pull= | |
| /48/files" target=3D"_blank">https://github.com/commons-rdf/commons-rdf/pul= | |
| l/48/files</a><br> | |
| >>>> and perhaps:<br> | |
| >>>> <a href=3D"https://github.com/commons-rdf/commons-rdf/pull= | |
| /61/files" target=3D"_blank">https://github.com/commons-rdf/commons-rdf/pul= | |
| l/61/files</a><br> | |
| >>>><br> | |
| >>>><br> | |
| >>>><br> | |
| >>>> I would then need to fix simple GraphImpl.add() to clone a= | |
| nd change<br> | |
| >>>> the local scope of the BlankNodes:<br> | |
| >>>> .. as otherwise it would wrongly merge graph1.b1 and graph= | |
| 2.b1 (in<br> | |
| >>>> both having the same internalIdentifier and the abstract L= | |
| ocal Scope<br> | |
| >>>> of being in the same Graph). This can happen if doing say = | |
| a copy from<br> | |
| >>>> one graph to another.<br> | |
| >>>><br> | |
| >>>> Raised and detailed in<br> | |
| >>>> <a href=3D"https://github.com/commons-rdf/commons-rdf/issu= | |
| es/66" target=3D"_blank">https://github.com/commons-rdf/commons-rdf/issues/= | |
| 66</a><br> | |
| >>>> .. adding this to the tests sounds crucial, and would help= | |
| us later<br> | |
| >>>> when sorting this.<br> | |
| >>>><br> | |
| >>>><br> | |
| >>>> This is in no way a complete resolution. (New bugs would a= | |
| rise, e.g.<br> | |
| >>>> you could add a triple with a BlankNode and then not remov= | |
| e it<br> | |
| >>>> afterwards with the same arguments).<br> | |
| >>>><br> | |
| >>>><br> | |
| >>>><br> | |
| >>>><br> | |
| >>>><br> | |
| >>>> On 22 March 2015 at 21:00, Peter Ansell <<a href=3D"mai= | |
| lto:ansell.peter@gmail.com">ansell.peter@gmail.com</a>> wrote:<br> | |
| >>>><br> | |
| >>>>> +1<br> | |
| >>>>><br> | |
| >>>>> Although it is not urgent to release a 1.0 version, it= | |
| is urgent to<br> | |
| >>>>> release (and keep releasing often) what we have change= | |
| d since 0.0.2 so<br> | |
| >>>>> we can start experimenting with it, particularly since= | |
| I have started<br> | |
| >>>>> more intently on Sesame 4 in the last few weeks. Stian= | |
| s pull requests<br> | |
| >>>>> to change the BNode situation could wait until after 0= | |
| .0.3 is<br> | |
| >>>>> released, at this point.<br> | |
| >>>>><br> | |
| >>>>> Cheers,<br> | |
| >>>>><br> | |
| >>>>> Peter<br> | |
| >>>>><br> | |
| >>>>> On 21 March 2015 at 22:37, Andy Seaborne <<a href= | |
| =3D"mailto:andy@apache.org">andy@apache.org</a>> wrote:<br> | |
| >>>>><br> | |
| >>>>>> I agree with Sergio that releasing something is im= | |
| portant.<br> | |
| >>>>>><br> | |
| >>>>>> We need to release, then independent groups can st= | |
| art to build on it.<br> | |
| >>>>>> We<br> | |
| >>>>>> have grounded requirements and a wider community.<= | |
| br> | |
| >>>>>><br> | |
| >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Andy<br> | |
| >>>>>><br> | |
| >>>>>><br> | |
| >>>>>> On 21/03/15 09:10, Reto Gm=C3=BCr wrote:<br> | |
| >>>>>><br> | |
| >>>>>>><br> | |
| >>>>>>> Hi Sergio,<br> | |
| >>>>>>><br> | |
| >>>>>>> I don't see where an urgent agenda comes f= | |
| rom. Several RDF APIs are<br> | |
| >>>>>>><br> | |
| >>>>>> there<br> | |
| >>>><br> | |
| >>>>> so a new API essentially needs to be better rather tha= | |
| n done with<br> | |
| >>>>>>><br> | |
| >>>>>> urgency.<br> | |
| >>>><br> | |
| >>>>><br> | |
| >>>>>>> The SPARQL implementation is less something th= | |
| at need to be part of<br> | |
| >>>>>>> the<br> | |
| >>>>>>> first release but something that helps validat= | |
| ing the API proposal.<br> | |
| > We<br> | |
| >>>>>>> should validate our API against many possible = | |
| usecases and then<br> | |
| > discus<br> | |
| >>>>>>> which are more important to support. In my opi= | |
| nion for an RDF API it<br> | |
| >>>>>>> is<br> | |
| >>>>>>> more important that it can be used with remote= | |
| repositories over<br> | |
| >>>>>>><br> | |
| >>>>>> standard<br> | |
| >>>><br> | |
| >>>>> protocols than support for hadoop style processing acr= | |
| oss many machines<br> | |
| >>>>>>> [1], but maybe we can support both usecases.<b= | |
| r> | |
| >>>>>>><br> | |
| >>>>>>> In any case I think its good to have prototypi= | |
| cal implementation of<br> | |
| >>>>>>> usecases to see what API features are needed a= | |
| nd which are<br> | |
| >>>>>>><br> | |
| >>>>>> problematic. So<br> | |
| >>>><br> | |
| >>>>> I would encourage to write prototype usecases where a = | |
| hadoop style<br> | |
| >>>>>>> processing shows the need for exposed blank no= | |
| de ID or a prototype<br> | |
| >>>>>>><br> | |
| >>>>>> showing<br> | |
| >>>><br> | |
| >>>>> that that IRI is better an interface than a class, etc= | |
| .<br> | |
| >>>>>>><br> | |
| >>>>>>> At the end we need to decide on the API featur= | |
| es based on the<br> | |
| > usecases<br> | |
| >>>>>>> they<br> | |
| >>>>>>> are required by respectively compatible with. = | |
| But it's hard to see<br> | |
| > the<br> | |
| >>>>>>> requirements without prototypical code.<br> | |
| >>>>>>><br> | |
| >>>>>>> Cheers,<br> | |
| >>>>>>> Reto<br> | |
| >>>>>>><br> | |
| >>>>>>> 1.<br> | |
| >>>>>>><br> | |
| >>>>>>>=C2=A0 <a href=3D"https://github.com/commons-rd= | |
| f/commons-rdf/pull/48#" target=3D"_blank">https://github.com/commons-rdf/co= | |
| mmons-rdf/pull/48#</a><br> | |
| >>>> issuecomment-72689214<br> | |
| >>>><br> | |
| >>>>><br> | |
| >>>>>>> On Fri, Mar 20, 2015 at 8:30 PM, Sergio Fern= | |
| =C3=A1ndez <<a href=3D"mailto:wikier@apache.org">wikier@apache.org</a>&g= | |
| t;<br> | |
| >>>>>>> wrote:<br> | |
| >>>>>>><br> | |
| >>>>>>>=C2=A0 I perfectly understand what you target. = | |
| But still, FMPOV still out<br> | |
| > of<br> | |
| >>>>>>>><br> | |
| >>>>>>> our<br> | |
| >>>><br> | |
| >>>>> urgent agenda. Not because it is not interesting, just= | |
| because more<br> | |
| >>>>>>>> urgent<br> | |
| >>>>>>>> things to deal with. I think the most impo= | |
| rtant think is to get<br> | |
| >>>>>>>><br> | |
| >>>>>>> running<br> | |
| >>>><br> | |
| >>>>> with what we have, and get a release out. But, as I sa= | |
| id, we can<br> | |
| >>>>>>>><br> | |
| >>>>>>> discuss<br> | |
| >>>><br> | |
| >>>>> it.<br> | |
| >>>>>>>><br> | |
| >>>>>>>><br> | |
| >>>>>>>> On 20/03/15 19:10, Reto Gm=C3=BCr wrote:<b= | |
| r> | |
| >>>>>>>><br> | |
| >>>>>>>>=C2=A0 Just a little usage example to illus= | |
| trate Stian's point:<br> | |
| >>>>>>>>><br> | |
| >>>>>>>>> public class Main {<br> | |
| >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public stat= | |
| ic void main(String... args) {<br> | |
| >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= | |
| =A0 Graph g =3D new SparqlGraph("<a href=3D"http://dbpedia.org/sparql"= | |
| target=3D"_blank">http://dbpedia.org/sparql</a>");<br> | |
| >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= | |
| =A0 Iterator<Triple> iter =3D g.filter(new Iri("<br> | |
| >>>>>>>>> <a href=3D"http://dbpedia.org/ontology= | |
| /Planet" target=3D"_blank">http://dbpedia.org/ontology/Planet</a>"),<b= | |
| r> | |
| >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= | |
| =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 new<br> | |
| >>>>>>>>> Iri("<a href=3D"http://www.w3.org= | |
| /1999/02/22-rdf-syntax-ns#type" target=3D"_blank">http://www.w3.org/1999/02= | |
| /22-rdf-syntax-ns#type</a><br> | |
| >>>>>>>>> "),<br> | |
| >>>>>>>>> null);<br> | |
| >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= | |
| =A0 while (iter.hasNext()) {<br> | |
| >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= | |
| =A0 =C2=A0 =C2=A0 System.out.println(iter.next().getObject());<br> | |
| >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= | |
| =A0 }<br> | |
| >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br> | |
| >>>>>>>>> }<br> | |
| >>>>>>>>><br> | |
| >>>>>>>>> I think with Stian's version using= | |
| streams the above could be<br> | |
| >>>>>>>>> shorter<br> | |
| >>>>>>>>> and<br> | |
| >>>>>>>>> nicer. But the important part is that = | |
| the above allows to use<br> | |
| >>>>>>>>><br> | |
| >>>>>>>> dbpedia as<br> | |
| >>>><br> | |
| >>>>> a<br> | |
| >>>>>>>>> graph without worrying about sparql.<b= | |
| r> | |
| >>>>>>>>><br> | |
| >>>>>>>>> Cheers,<br> | |
| >>>>>>>>> Reto<br> | |
| >>>>>>>>><br> | |
| >>>>>>>>> On Fri, Mar 20, 2015 at 4:16 PM, Stian= | |
| Soiland-Reyes <<br> | |
| >>>>>>>>><br> | |
| >>>>>>>> <a href=3D"mailto:stain@apache.org">stain@= | |
| apache.org</a>><br> | |
| >>>><br> | |
| >>>>> wrote:<br> | |
| >>>>>>>>><br> | |
| >>>>>>>>>=C2=A0 =C2=A0 I think a query interface= | |
| as you say is orthogonal to Reto's<br> | |
| >>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>> impl.sparql module - which is tryi= | |
| ng to be an implementation of<br> | |
| > RDF<br> | |
| >>>>>>>>>> Commons that is backed only by a r= | |
| emote SPARQL endpoint.=C2=A0 Thus it<br> | |
| >>>>>>>>>> touches on important edges like st= | |
| reaming and blank node<br> | |
| >>>>>>>>>> identities.<br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>> It's not a SPARQL endpoint bac= | |
| ked by RDF Commons! :-)<br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>> On 20 March 2015 at 10:58, Sergio = | |
| Fern=C3=A1ndez <<a href=3D"mailto:wikier@apache.org">wikier@apache.org</= | |
| a>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>> wrote:<br> | |
| >>>><br> | |
| >>>>><br> | |
| >>>>>>>>>>=C2=A0 Hi Reto,<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>> yes, that was a deliberated de= | |
| cision on early phases. I'd need to<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>> look<br> | |
| >>>><br> | |
| >>>>> it<br> | |
| >>>>>>>>>>> up, I do not remember the conc= | |
| rete issue.<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>> Just going a bit deeper into t= | |
| he topic, in querying we are<br> | |
| > talking<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>> not<br> | |
| >>>><br> | |
| >>>>><br> | |
| >>>>>>>>>>>=C2=A0 only<br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 about providing native suppo= | |
| rt to query Graph instance, but also<br> | |
| >>>>>>>>>>> to<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>>=C2=A0 provide<br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 common interfaces to interac= | |
| t with the results.<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>> The idea was to keep the focus= | |
| on RDF 1.1 concepts before moving<br> | |
| >>>>>>>>>>> to<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>>=C2=A0 query.<br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 Personally I'd prefer to= | |
| keep that scope for the first incubator<br> | |
| >>>>>>>>>>> release,<br> | |
| >>>>>>>>>>> and then start to open discuss= | |
| ions about such kind of threads.<br> | |
| > But<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>> of<br> | |
| >>>><br> | |
| >>>>><br> | |
| >>>>>>>>>>>=C2=A0 course<br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 we can vote to change that a= | |
| pproach.<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>> Cheers,<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>> On 17/03/15 11:05, Reto Gm=C3= | |
| =BCr wrote:<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>>> Hi Sergio,<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>> I'm not sure which del= | |
| iberate decision you are referring to, is<br> | |
| >>>>>>>>>>>> it<br> | |
| >>>>>>>>>>>> Issue<br> | |
| >>>>>>>>>>>> #35 in Github?<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>> Anyway, the impl.sparql co= | |
| de is not about extending the API to<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>> allow<br> | |
| >>>><br> | |
| >>>>> running queries on a graph, in fact the API isn't = | |
| extended at all.<br> | |
| >>>>>>>>>>>> It's<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>>=C2=A0 an<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 implementation of the API wh= | |
| ich is backed by a SPARQL endpoint.<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>> Very<br> | |
| >>>><br> | |
| >>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>>=C2=A0 often<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 the triple store doesn't= | |
| run in the same VM as the client and so<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>> it is<br> | |
| >>>><br> | |
| >>>>><br> | |
| >>>>>>>>>>>> necessary that implementat= | |
| ion of the API speak to a remote<br> | |
| > triple<br> | |
| >>>>>>>>>>>> store.<br> | |
| >>>>>>>>>>>> This can use some propriet= | |
| ary protocols or standard SPARQL, this<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>> is<br> | |
| >>>><br> | |
| >>>>> an<br> | |
| >>>>>>>>>>>> implementation for SPARQL = | |
| and can thus be used against any<br> | |
| > SPARQL<br> | |
| >>>>>>>>>>>> endpoint.<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>> Cheers,<br> | |
| >>>>>>>>>>>> Reto<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>> On Tue, Mar 17, 2015 at 7:= | |
| 41 AM, Sergio Fern=C3=A1ndez <<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>> <a href=3D"mailto:wikier@apach= | |
| e.org">wikier@apache.org</a>><br> | |
| >>>><br> | |
| >>>>> wrote:<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>>=C2=A0 =C2=A0 Hi Reto,<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> thanks for updating us= | |
| with the status from Clerezza.<br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> In the current Commons= | |
| RDF API we delivery skipped querying for<br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>> the<br> | |
| >>>><br> | |
| >>>>><br> | |
| >>>>>>>>>>>>>=C2=A0 early<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 versions.<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> Although I'd prefe= | |
| r to keep this approach in the initial steps<br> | |
| >>>>>>>>>>>>> at<br> | |
| >>>>>>>>>>>>> ASF<br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>=C2=A0 (I<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 hope we can import the code = | |
| soon...), that's for sure one of the<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>> next<br> | |
| >>>><br> | |
| >>>>><br> | |
| >>>>>>>>>>>>> points to discuss in t= | |
| he project, where all that experience is<br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>=C2=A0 valuable.<br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>>=C2=A0 Cheers,<br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> On 16/03/15 13:02, Ret= | |
| o Gm=C3=BCr wrote:<br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>=C2=A0 =C2=A0 Hello,<br= | |
| > | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>> With the new repos= | |
| itory the clerezza rdf commons previously in<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> the<br> | |
| >>>><br> | |
| >>>>> commons<br> | |
| >>>>>>>>>>>>>> sandbox are now at= | |
| :<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>> <a href=3D"https:/= | |
| /git-wip-us.apache.org/repos/asf/clerezza-rdf-core.git" target=3D"_blank">h= | |
| ttps://git-wip-us.apache.org/repos/asf/clerezza-rdf-core.git</a><br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>> I will compare tha= | |
| t code with the current status of the code<br> | |
| > in<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> the<br> | |
| >>>><br> | |
| >>>>> incubating rdf-commons project in a later mail.<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>> Now I would like t= | |
| o point to your attention a big step forward<br> | |
| >>>>>>>>>>>>>> towards<br> | |
| >>>>>>>>>>>>>> CLEREZZA-856. The = | |
| impl.sparql modules provide an<br> | |
| > implementation<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> of<br> | |
| >>>><br> | |
| >>>>> the<br> | |
| >>>>>>>>>>>>>> API<br> | |
| >>>>>>>>>>>>>> on top of a SPARQL= | |
| endpoint. Currently it only supports read<br> | |
| >>>>>>>>>>>>>> access.<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>>=C2=A0 For<br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 usage example see the tests = | |
| in<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>> /src/test/java/org= | |
| /apache/commons/rdf/impl/sparql (<br> | |
| >>>>>>>>>>>>>> <a href=3D"https:/= | |
| /git-wip-us.apache.org/repos/asf?p=3Dclerezza-rdf-core" target=3D"_blank">h= | |
| ttps://git-wip-us.apache.org/repos/asf?p=3Dclerezza-rdf-core</a>.<br> | |
| >>>>>>>>>>>>>> git;a=3Dtree;f=3Di= | |
| mpl.sparql/src/test/java/org/apache/commons/<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>>=C2=A0 rdf/impl/spa= | |
| rql;h=3Dcb9c98bcf427452392e74cd162c08a<br> | |
| >>>> b308359c13;hb=3DHEAD<br> | |
| >>>><br> | |
| >>>>> )<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>> The hard part was = | |
| supporting BlankNodes. The current<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> implementation<br> | |
| >>>><br> | |
| >>>>> handles<br> | |
| >>>>>>>>>>>>>> them correctly eve= | |
| n in tricky situations, however the current<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> code<br> | |
| >>>><br> | |
| >>>>> is<br> | |
| >>>>>>>>>>>>>> not<br> | |
| >>>>>>>>>>>>>> optimized for perf= | |
| ormance yet. As soon as BlankNodes are<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> involved<br> | |
| >>>><br> | |
| >>>>> many<br> | |
| >>>>>>>>>>>>>> queries have to be= | |
| sent to the backend. I'm sure some SPARQL<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> wizard<br> | |
| >>>><br> | |
| >>>>> could<br> | |
| >>>>>>>>>>>>>> help making things= | |
| more efficient.<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>> Since SPARQL is th= | |
| e only standardized methods to query RDF<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> data, I<br> | |
| >>>><br> | |
| >>>>><br> | |
| >>>>>>>>>>>>>>=C2=A0 think<br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 being able to fa=C3=A7ade an= | |
| RDF Graph accessible via SPARQL is an<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>>=C2=A0 important<br= | |
| > | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>>=C2=A0 usecase for an RDF API, so i= | |
| t would be good to also have an<br> | |
| > SPARQL<br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>> backed<br> | |
| >>>>>>>>>>>>>> implementation of = | |
| the API proposal in the incubating<br> | |
| >>>>>>>>>>>>>> commons-rdf<br> | |
| >>>>>>>>>>>>>> repository.<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>> Cheers,<br> | |
| >>>>>>>>>>>>>> Reto<br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>>>=C2=A0 =C2=A0 --<br= | |
| > | |
| >>>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>> Sergio Fern=C3=A1ndez<= | |
| br> | |
| >>>>>>>>>>>>> Partner Technology Man= | |
| ager<br> | |
| >>>>>>>>>>>>> Redlink GmbH<br> | |
| >>>>>>>>>>>>> m: <a href=3D"tel:%2B4= | |
| 3%20660%202747%20925" value=3D"+436602747925">+43 660 2747 925</a><br> | |
| >>>>>>>>>>>>> e: <a href=3D"mailto:s= | |
| ergio.fernandez@redlink.co">sergio.fernandez@redlink.co</a><br> | |
| >>>>>>>>>>>>> w: <a href=3D"http://r= | |
| edlink.co" target=3D"_blank">http://redlink.co</a><br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>><br> | |
| >>>>>>>>>>>>=C2=A0 --<br> | |
| >>>>>>>>>>> Sergio Fern=C3=A1ndez<br> | |
| >>>>>>>>>>> Partner Technology Manager<br> | |
| >>>>>>>>>>> Redlink GmbH<br> | |
| >>>>>>>>>>> m: <a href=3D"tel:%2B43%20660%= | |
| 202747%20925" value=3D"+436602747925">+43 660 2747 925</a><br> | |
| >>>>>>>>>>> e: <a href=3D"mailto:sergio.fe= | |
| rnandez@redlink.co">sergio.fernandez@redlink.co</a><br> | |
| >>>>>>>>>>> w: <a href=3D"http://redlink.c= | |
| o" target=3D"_blank">http://redlink.co</a><br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>> --<br> | |
| >>>>>>>>>> Stian Soiland-Reyes<br> | |
| >>>>>>>>>> Apache Taverna (incubating), Apach= | |
| e Commons RDF (incubating)<br> | |
| >>>>>>>>>> <a href=3D"http://orcid.org/0000-0= | |
| 001-9842-9718" target=3D"_blank">http://orcid.org/0000-0001-9842-9718</a><b= | |
| r> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>><br> | |
| >>>>>>>>>=C2=A0 --<br> | |
| >>>>>>>> Sergio Fern=C3=A1ndez<br> | |
| >>>>>>>> Partner Technology Manager<br> | |
| >>>>>>>> Redlink GmbH<br> | |
| >>>>>>>> m: <a href=3D"tel:%2B43%20660%202747%20925= | |
| " value=3D"+436602747925">+43 660 2747 925</a><br> | |
| >>>>>>>> e: <a href=3D"mailto:sergio.fernandez@redl= | |
| ink.co">sergio.fernandez@redlink.co</a><br> | |
| >>>>>>>> w: <a href=3D"http://redlink.co" target=3D= | |
| "_blank">http://redlink.co</a><br> | |
| >>>>>>>><br> | |
| >>>>>>>><br> | |
| >>>>>>><br> | |
| >>>>>><br> | |
| >>>><br> | |
| >>>><br> | |
| >>>> --<br> | |
| >>>> Stian Soiland-Reyes<br> | |
| >>>> Apache Taverna (incubating), Apache Commons RDF (incubatin= | |
| g)<br> | |
| >>>> <a href=3D"http://orcid.org/0000-0001-9842-9718" target=3D= | |
| "_blank">http://orcid.org/0000-0001-9842-9718</a><br> | |
| >>>><br> | |
| >>>><br> | |
| >>><br> | |
| >><br> | |
| </blockquote></div> | |
| --001a11c1b4241bfd0d05122d2dd0-- |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment