Closed eroux closed 5 years ago
I dont really see the benefits of using such detailed and complex key/value pairs in props files, in particular because only
updateModelUrl=http://purl.bdrc.io/authmodel
authUpdatePath=http://purl.bdrc.io/authmodel/updated
can change over different BUDA instances (Github links, Ontology URIs, prefixes and schemas names stay the same). So we could eventually have for these two lines a serverRoot=http://purl.bdrc.io
or serverRootRoot=http://localhost:13280
along with updateModelUrl=/authmodel
& authUpdatePath=/updated
. This would allow for setting up BUDA differently according to our needs (dev, test or deployment).
Other than that, it seems to me that such a hierachical structure for props keys would be more relevant and needed if we had all props of BUDA in a single file, shared in a single java Properties object. Let's talk about this as I might be missing the key point of your request.
@MarcAgate a reasonable observation for stable code base; however, it's worth considering development scenarios in which we might want to use a different ontology or fuseki endpoints or use GitLab and so on. Perhaps these sorts of scenarios would justify a more detailed property structure
I'd like to come back to this as the main use case is getting more realistic: if a partner (like DILA) wants to use lds-pdi, they need to be able to configure the ontologies they want to serve. That's the main benefit of the detailed and complex key/value pairs in props files, but I'm open to a more simple one
I am still not sure I fully get what is at stake here. What is the exact meaning of "serving different ontologies using ldspdi"? Does it mean as I understand it, a different dataset (fuseki endpoint) and a different LD structure and vocabulary, along with different query or graph templates? If so, tweaking the properties files might not be sufficient and I need to review the code accordingly so it can flawlessly support this feature.
in fact this more generic solution would work even better, I write it in Yaml as it's unreadable in properties format
staticdatasets: [
core: {
parts: {
core-rdfs: {
fileurl: https://github.com/buda-base/owl-schema/raw/master/bdo.ttl,
type: rdfs,
endpoint: /ontology/core
},
core-owl: {
fileurl: https://github.com/buda-base/owl-schema/raw/master/bdo.owl.ttl,
type: owl,
endpoint: /ontology/core.owl
}
core-shapes: {
fileurl: https://github.com/buda-base/owl-schema/raw/master/bdo.shacl.ttl,
type: shacl,
endpoint: /ontology/core.shapes
}
},
type: rdfs,owl,shacl,
endpoint: /ontology/core.merged
},
# same for adm, auth, etc.
]
pathMappings: [
{ # this basically says that when the user is hitting the path /ontology/x/y.z it should look for the property or dataset http://purl.bdrc.io/ontology/x/y.z
orig: http://purl.bdrc.io/ontolgy
dest: /ontology
}
]
The context thing wouldn't change (although it could be converted to yaml)
io.bdrc.ldspdi.contexts=bdo
io.bdrc.ldspdi.contexts.bdo.dlurl=https://raw.githubusercontent.com/buda-base/owl-schema/master/context.jsonld
io.bdrc.ldspdi.contexts.bdo.path=/context.jsonld
io.bdrc.ldspdi.contexts.bdo.updateHookPath=/updateHook
All this has been addressed by using ontDocManager and https://github.com/buda-base/owl-schema/blob/master/ont-policy.rdf
yes, thanks!
Instead of having hardcoded things like
we could have something more generic and scalable like: