On Thu, Apr 16, 2015 at 7:41 AM, Sergio Fernández <wik...@apache.org> wrote:
> Hi, > > On Wed, Apr 15, 2015 at 12:30 PM, Reto Gmür <r...@apache.org> wrote: > > > On Wed, Apr 15, 2015 at 7:15 AM, Sergio Fernández <wik...@apache.org> > > wrote: > > > > > On Wed, Apr 15, 2015 at 2:20 AM, Peter Ansell <ansell.pe...@gmail.com> > > > wrote: > > > > > > > > BlankNodes cannot be compared across different SPARQL queries. That > is > > > > a well known RDF issue, not just with SPARQL, and is not going to be > > > > solved by anything except bulk execution of a single query to get all > > > > of the BlankNodes back in a single query. > > > > > > > > > I think that's something where we all can agree, isn't it? > > > > > > > No, there is no need to get all of the blank-nodes (of the graph) back. > > It's enough to get the context (aka minimum self contained graph, aka > > symmetric concise bounded description), this is what impl.sparql in > > clerezza commons RDF does. That's why if we have to assign a string > > identifier to it this would have to be a strong digest of this context > > graph and an indicator of the position of the node within it. > > > I could understand that need, but i still think is a very concrete use > case. Therefore I'd prefer to keep the api contracts as they were, keeping > such concrete aspect up to each implementation. > > Is that something what we could agree on? > Not sure what the agreement would be. The API are being redefined. For example apparently there has been a "decision" somewhere (maybe on Github?) that BlankNode identity should no longer be scoped but depend exclusively on their ID. I've just presented two usecases where a BlankNode ID is problematic, as the BlankNode ID is not part of the RDF spec I suggest not to have it in the API, but as there seem to exist strong opinion to keep the BlankNode ID I've created COMMONSRDF-13 inviting to show some concrete code that benefits from having such an ID exposed, of course this would also allow me to show if this usecases can be rewritten without the exposed IDs. Cheers, Reto > > Thanks. > > Cheers, > > -- > Sergio Fernández > Partner Technology Manager > Redlink GmbH > m: +43 6602747925 > e: sergio.fernan...@redlink.co > w: http://redlink.co >