[ 
https://issues.apache.org/jira/browse/COMMONSRDF-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492570#comment-14492570
 ] 

Reto Gmür commented on COMMONSRDF-13:
-------------------------------------

- Re first: I was referring to the current definition of the API, just a 
discussion on the mailing list (link please) does not fix the issue.

- Re second: What has this to do with exposed identifier? a.equals(b) is always 
false if a i a BlankNode and b a Literal.

- Re third: this might be a candidate for an example as requested by this 
issue, I claim however that this can as well be implemented without exposing 
the identifier, the instances returned by the parsers would internally have the 
identifier from the parsed file and evaluate to true if and only if this 
identifier is the same and they originate from the same parser invocation.

This issue is just about getting evidence for the pragmatic usefulness, 
evidence for the pragmatic difficulties has been shown by the SPARQL backend 
(http://mail-archives.apache.org/mod_mbox/commonsrdf-dev/201503.mbox/%3CCALvhUEXSSwO-Udj6ngdedVQuPC6n=+983ubnkyobs2psy5k...@mail.gmail.com%3E)
 as well as by the discussions in COMMONSRDF-6. However I think that given the 
RDF abstract syntax which in my opinion should be modeled by our API does not 
define any identifier for blank nodes the burden of proof for introducing them 
nevertheless should be on the advocates of their pragmatic advantages.
 
I'm sorry if you feel that I'm ignoring conclusive arguments already presented, 
please present them here preferably in the form of some code.


> 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)

Reply via email to