[
https://issues.apache.org/jira/browse/COMMONSRDF-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ansell resolved COMMONSRDF-13.
------------------------------------
Resolution: Incomplete
Assignee: Peter Ansell
Hi Reto,
I would like to immediately address three assertions that you made above that
are not in line with the discussion on the mailing list so far.
The first is the assertion that BlankNode.equals depends on the RDFTermFactory.
We have agreed recently (last 24/48 hours) that any ambiguity in that must be
cleared up to indicate that the internalIdentifier is the sole factor for
BlankNode equality. Hence, there need be no further reference to RDFTermFactory
in that context.
The second is that the assertion that because the RDF-1.1 Abstract Data Model
assumes an infinite disjoint set for BlankNodes, compared to both the sets for
IRI and Literal, that we must implement the interface that way.
The third is your omission of the evidence that I gave on the mailing list with
regard to constant memory streaming parsers, which has also been brought up in
the past many times.
I am closing this as your description is not accurate to the current situation.
Could you start another issue that asserts the benefits of not having
.internalIdentifier and why Clerezza cannot emit these values, rather than
continuing to ignore the pragmatic usefulness of BlankNode.internalIdentifier.
> Demo-code to show advantages of exposed Blank Node identifier
> -------------------------------------------------------------
>
> Key: COMMONSRDF-13
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-13
> Project: Apache Commons RDF
> Issue Type: Improvement
> Reporter: Reto Gmür
> Assignee: Peter Ansell
>
> Like many APIs but unlike the RDF Data model the BlankNode interface exposes
> an internal identifier. BlankNodes with the same identifier are mandated to
> be equals if the are created with the same RDFTermFactory.
> The concept of identifier has a match in many concrete syntaxes, however the
> usage in the API is different, as a graph may have different BNodes with the
> same identifier if they are created by different factories.
> The blank node identifier has been causing difficulties and been the subject
> to discussions. It is particularly problematic onbackend that do not expose
> such identifiers but which allow modifications (e.g. SPARQL backend), see
> also:
> http://mail-archives.apache.org/mod_mbox/commonsrdf-dev/201503.mbox/%3CCALvhUEXSSwO-Udj6ngdedVQuPC6n=+983ubnkyobs2psy5k...@mail.gmail.com%3E.
> To allow some evidence based discussion with this issue I ask proponent of
> exposing the blank node ID to provide some minimal code examples showing the
> advantage of having the ID exposed, i.e. code that could not easily be
> written without the BlankNode.internalIdentifier() method and the
> RDFTermFGactory.createBlankNode(String identifier) method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
