init jena data resolver

[architolk]

First concept - not yet finished (don't merge with master):

• TO DISCUSS: Should the source of the triples be a separate configuration entry from dataSource, as it is currently ("source" entry - can be a file or an URI). An how could a sparql endpoint be reached?
• TO DISCUSS: Should templates and configuration be part of the scr tree (and compiled to the executable) or separate from the executable

Limitations:

• Only SELECT queries are supported, Only list-of-maps are supported
• Maps as output are not supported (would probably be a list-of-maps);
• SELECT queries are currently not parameterable (this might not be needed, but gives an issue if you want to create tables within tables with select queries)
• The config yml and template definition is part of the codebase, the input & sparql queries are outside the codebase

Code consideration:

• Maybe create an abstract class for the SPARQL endpoints, so we could manage Jena-specific code better.
• Unit test should be added

[pmaria]

Should templates and configuration be part of the scr tree (and compiled to the executable) or separate from the executable

Both should be, and are, currently possible (needs testing).

[Bakkej]

Should templates and configuration be part of the scr tree (and compiled to the executable) or separate from the executable

Both should be, and are, currently possible (needs testing).

So you're suggesting that we'd have a 'default' template/configuration set at build time, which could be 'overwritten' by passing arguments at run time?
could this result in both:
-> java - jar rdf-template.jar --input input.ttl
and
-> java -jar rdf-template.jar --input input.ttl --config config.yml --template template.yml
being valid?

[pmaria]

Should templates and configuration be part of the scr tree (and compiled to the executable) or separate from the executable

Both should be, and are, currently possible (needs testing).

So you're suggesting that we'd have a 'default' template/configuration set at build time, which could be 'overwritten' by passing arguments at run time? could this result in both: -> java - jar rdf-template.jar --input input.ttl and -> java -jar rdf-template.jar --input input.ttl --config config.yml --template template.yml being valid?

No, sorry I wasn't clear in my response. The idea is that both should be possible in the core and data-resolver components. It would be up to the app builder using these components to decide what to do.

Currently, we have a util class ConfigResourceLoaders which first checks if a resouce is available externally, and if not, will check the classpath in the packaged artifact.

For the default app we provide, external configuration makes sense.

[architolk]

I hadn't currently used the ConfigResourceLoaders in the Jena-part, I will enhance that bit of the code.

[pmaria]

@architolk I added the config resource loader and cleaned up the code a bit. Will take another look at the config later on to see how we can optimize