more generic configuration for ontologies / schemas service

[eroux]

Instead of having hardcoded things like

#ontology url
owlURL=https://raw.githubusercontent.com/buda-base/owl-schema/master/bdrc.owl
#ontology url
owlAuthURL=https://raw.githubusercontent.com/buda-base/owl-schema/master/auth.owl

#ontology graph name
ontGraph=http://purl.bdrc.io/ontology/core/ontologySchema
authGraph=http://purl.bdrc.io/ontology/ext/authSchema

#common buda properties
authDataGraph=http://purl.bdrc.io/ontology/ext/authData
updateModelUrl=http://purl.bdrc.io/authmodel

#Json context url
jsonContextURL=https://raw.githubusercontent.com/buda-base/owl-schema/master/context.jsonld

we could have something more generic and scalable like:

io.bdrc.ldspdi.ontologies=core,auth
io.bdrc.ldspdi.ontologies.core.dlurl=https://raw.githubusercontent.com/buda-base/owl-schema/master/bdrc.owl
io.bdrc.ldspdi.ontologies.pathMap.orig=http://purl.bdrc.io/ontolgy/core
io.bdrc.ldspdi.ontologies.pathMap.dest=/ontology/core
io.bdrc.ldspdi.ontologies.core.fusekiGraph=http://purl.bdrc.io/ontology/core/ontologySchema
io.bdrc.ldspdi.ontologies.core.updateHookPath=/updateHook

io.bdrc.ldspdi.ontologies.auth.dlurl=https://raw.githubusercontent.com/buda-base/owl-schema/master/auth.owl

etc.

io.bdrc.ldspdi.contexts=core
io.bdrc.ldspdi.contexts.core.dlurl=https://raw.githubusercontent.com/buda-base/owl-schema/master/context.jsonld
io.bdrc.ldspdi.contexts.core.path=/context.jsonld
io.bdrc.ldspdi.contexts.core.updateHookPath=/updateHook

[MarcAgate]

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.

[xristy]

@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

[eroux]

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

[MarcAgate]

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.

[eroux]

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

[MarcAgate]

All this has been addressed by using ontDocManager and https://github.com/buda-base/owl-schema/blob/master/ont-policy.rdf

[eroux]

yes, thanks!