[COMMONSRDF-13] Demo-code to show advantages of exposed Blank Node identifier

• Type: Improvement
• Status: Reopened
• Priority: Major
• Resolution: Unresolved
• Assignee: Unassigned
• Reporter: Reto Gmür
• Created: 11/Apr/15 11:35
• Updated: 27/Oct/16 09:07

Description

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=[e-mail]%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.

Issue Links

• blocks: COMMONSRDF-6 Contract around the internal string of a blank node