Skip to end of metadata
Go to start of metadata

The work below elaborates on the entity changes needed for adding NL support to KRMS. Contract is in the works and will be shared here.
Here is the overall KRMS schema with NL extension:

The following entity captures the usage context for a template:

Dynamic attributes for the above follows:

The natural language usage context needs to be related to the proposition it applies to. The template is assumed to be velocity template as currently used in the KS Statement service:

Issues:

  • Do we need to constrain the types that will have NL associated with them ?
  • Do we want to have dynamic attributes or live without them ?

2 Comments

  1. On the issues:
    (1) Do we need to constrain the types that will have NL associated with them ?
    my gut is that it is better to not constrain which types have NL associated with them I can see the possibility that Agenda types would eventually have NL associated with them.

    (2) Do we want to have dynamic attributes or live without them ?
    Put them on just in case... there is always a need to hold extra data for some use cases and we don't want to have to change the database.

    1. We've discussed and think we can live without the Usage dynamic attributes.