GH-3992 add sparql parser default prefixes

[ate47]

GitHub issue resolved: #3992

Briefly describe the changes proposed in this PR:

This PR add a constructor to the SPARQLParser class and a new method in the SPARQLParserFactory to add custom default prefixes to the parser.

// SPARQLParser
SPARQLParser(Set<Namespace> customDefaultPrefixes)

// SPARQLParserFactory
QueryParser getParser(Set<Namespace> customDefaultPrefixes);

Example

// create a set with the ex namespace 
Set<Namespace> customDefaultPrefixes = new HashSet<>();
customDefaultPrefixes.add(Values.namespace("ex", "http://example.org/"));

// create a parser with the default prefixes
SPARQLParser parser = new SPARQLParser(customDefaultPrefixes);

// we can use the default prefix without having to specify it
parser.parseQuery("SELECT ?s {?s ex:aaa ex:ooo}", null);

// we can redefine the prefix in the query if we want another one (this is not an error)
parser.parseQuery("PREFIX ex: <http://example2.org/> SELECT ?s {?s ex:aaa ex:ooo}", null);


// we cannot redefine a prefix in the same request (this is still an excepted error)
parser.parseQuery("PREFIX ex: <http://example.org/> PREFIX ex: <http://example2.org/> SELECT ?s {?s ex:aaa ex:ooo}", null);

---

PR Author Checklist (see the contributor guidelines for more details):

• my pull request is self-contained
• I've added tests for the changes I made
• I've applied code formatting (you can use mvn process-resources to format from the command line)
• I've squashed my commits where necessary
• every commit message starts with the issue number (GH-xxxx) followed by a meaningful description of the change

[barthanssens]

Hi,

thanks for the PR, just wondering if e.g. a Set<Namespace> might be more elegant.
That would also allow for (re)using the predefined namespaces from org.eclipse.rdf4j.model.vocabulary....

[ate47]

True! I wasn't aware of the existence of this package, I've replaced the map to a set parameter

[EmptyStar]

I'd like to make a case for using Collections.emptyMap() in favor of passing around null for the custom prefix map. Your code would be simpler and probably safer if you could always assume the prefix map to exist. I pointed out a few bits of code that could be made more elegant with an empty map.

[ate47]

I'd like to make a case for using Collections.emptyMap() in favor of passing around null for the custom prefix map. Your code would be simpler and probably safer if you could always assume the prefix map to exist. I pointed out a few bits of code that could be made more elegant with an empty map.

Yes, I was a bit lazy to check if the PrefixDeclProcessor was used anywhere else to be able to remove use null instead, but after a check, it is not.

[D063520]

Hi, is there something blocking? I'm in favour of this pull request : )

[barthanssens]

Thanks for the enhancement !
Perhaps the only thing left to do would be squashing the commits (see also https://rdf4j.org/documentation/developer/squashing/ on how to do this, and https://rdf4j.org/documentation/developer/merge-strategy/ why this is a probably a good idea)

[ate47]

Thanks for the enhancement ! Perhaps the only thing left to do would be squashing the commits (see also https://rdf4j.org/documentation/developer/squashing/ on how to do this, and https://rdf4j.org/documentation/developer/merge-strategy/ why this is a probably a good idea)

Done, I was thinking it was squashed enough.

[hmottestad]

I've added some comments. If you agree with my comments then ping me with @hmottestad when you're done and I'll merge this PR so it will be included in the upcoming 4.1.0 release.