ruby-rdf / rdf-turtle

Turtle reader/writer for Ruby
http://rubygems.org/gems/rdf-turtle
The Unlicense
31 stars 9 forks source link

Nil prefix and base_uri #15

Closed djboardman closed 5 years ago

djboardman commented 5 years ago

Hi

This maybe just a misunderstanding of mine about prefixes and base URI but...

I can specify base_uri and get what I expected if there are no prefixes at all in the statement:

base_uri = "http://baseuri/"
statement = ":david :place :st-albans"
r = RDF::Turtle::Reader.new(statement,  base_uri: base_uri)

produces the following when I get the statement:

#<RDF::Statement:0x105228c(<http://baseuri/david> <http://baseuri/place> <http://baseuri/st-albans> .)> 

But if I include a prefix in the statement and add a prefixes hash I get an error:

base_uri = "http://baseuri/"
prefixes = {rdf: "http://www.w3.org/1999/02/22-rdf-syntax-ns#"}
statement = ":david rdf:type :homosapien" 
r = RDF::Turtle::Reader.new(statement,  base_uri: base_uri, prefixes: prefixes)

produces the following error when I get the statement:

ERROR [line 1] undefined prefix: {:production=>:pname, :token=>""}: 
FATAL recovery:   iri: []
FATAL recovery:   subject: []
FATAL recovery:   triples: ["."]
FATAL recovery:   statement: ["."]
 => nil 

I can fix this by including a nil prefix

prefixes = {rdf: "http://www.w3.org/1999/02/22-rdf-syntax-ns#", nil => base_uri}
r = RDF::Turtle::Reader.new(statement, base_uri: base_uri, prefixes: prefixes)

which produces:

#<RDF::Statement:0x13a5394(<http://baseuri/david> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://baseuri/homosapien> .)> 

Is this expected behaviour?

Thanks

gkellogg commented 5 years ago

I'm not able to repeat the second case, where prefixes is defined, as errors are only raised when validating. If not validating, the prefixes option is automatically set to {nil => ""}, as this is a common idiom, although it does not create valid RDF unless base_uri is also defined.

The code should merge {nil => ""} into prefixes if it is defined to support this use case.

However, ReaderError is only raised when validating, so neither case would have resulted in an error.