Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Statements w/ Blank Nodes can be duplicated in serialized output #261

Closed
no-reply opened this issue Jan 17, 2016 · 2 comments
Closed

Statements w/ Blank Nodes can be duplicated in serialized output #261

no-reply opened this issue Jan 17, 2016 · 2 comments

Comments

@no-reply
Copy link
Member

The definition of blank node equality runs afoul of keyspace definition for Ruby Hashes. This leads to repeated inserts of blank nodes that satisfy #==, and the same #id and `#hash, when they are not exactly the same object.

repo = RDF::Repository.new

repo.insert([RDF::Node.new('s'), RDF::URI('http://ex.org/p'), 'o'])
repo.insert([RDF::Node.new('s'), RDF::URI('http://ex.org/p'), 'o'])

repo.dump :ntriples
# => "_:s <http://ex.org/p> \"o\" .\n_:s <http://ex.org/p> \"o\" .\n"

A (proposed) failing test for this is at rdf-spec. An alternate solution is to continue to fail that test, but check that internally unique blank nodes are reflected as such in serialized output.

@gkellogg
Copy link
Member

This is a serializer issue, isn't it? There's a :unique_bnodes option to Writer that re-issues BNode identifiers because of this reason; mostly, people expect to see the same BNode identifier used when re-serializing, so it's not the default.

You are inserting two different nodes, so they should be two different statements.

Alternatively, Writer could scan the graph/repo to look for BNodes with the same id which are different nodes and modify the id; however, Writer doesn't operate on graph/repo, but on each statement coming in, so it would probably need to keep a local memory and this could get ugly.

@no-reply
Copy link
Member Author

The proposed solutions to this are broken down into #262 and #263. The issue is represented correctly by those tickets.

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants