-
Notifications
You must be signed in to change notification settings - Fork 4
Creating a new class with an auto-allocated ID #56
Description
Currently, users wanting to create a new class using KGCL are expected to know in advance the ID of the class to be created, so that they can issue a create class ID:1234 "label" command.
This is hardly compatible with the intended use of KGCL in bug tracker tickets.
There would be several ways to address the problem.
A. Non-technical solution. Leave KGCL as it is, but expect that ontologies should have a ID range specifically intended for KGCL change and document that range to users.
Not ideal as it puts all the burden of allocating the ID to the users (who must first figure out what is the range allocated to KGCL-mediated changes, and then find out what is the lowest non-used ID in that range).
This is, in effect, the current situation.
B. Deal with auto IDs at the level of the Ontobot. Leave KGCL as it is. Agree on a special keyword (for example ID:auto) to use in the KGCL DSL syntax, and have Ontobot automatically replace that keyword by a suitable auto-generated ID before actually passing the KGCL data to the KGCL library. It’s up to the Ontobot to figure out how to allocated ID (probably by parsing the -idranges.owl file, if such a file exists).
C. Similar as B, but at the level of KGCL itself. That is, the KGCL DSL explicitly defines the ID:auto keyword, and KGCL libraries are expected to know that they should automatically allocate an ID when this keyword is used.
I currently think this would be the best solution.
Both B and C would allow an user to something like this:
create class ID:auto "new label"
add definition "new definition" to ID:auto
create edge ID:auto rdfs:subClassOf EX:1234
D. Add variables to the KGCL DSL. Make it possible to do something like this:
let my_new_class = create class "new label"
add definition "my definition" to my_new_class
create edge my_new_class rdfs:subClassOf EX:1234
Technically speaking the most elegant solution, but I don’t think we want to add such constructs to the KGCL DSL syntax – which is expected to be a simple syntax for mostly non-technical users.