Mapping named things: concepts, relations, rules, interfaces, etc.

[stefjoosten]

Problem

As an Ampersand user, I may want to reuse an existing dataset for many reasons. For example, I might want to add new functionality, I may want to tap into an existing dataset, I might want to migrate data into a new application, or I may want to verify the consistency of data across the borders of multiple datasets. In all cases, I want to read another database while renaming some of the items. This issue assumes that I do NOT want to change its schema because it is being used by others, who must continue what they are doing. Yet, I DO want to change its schema because I need to rename certain concepts, relations, rules, and other named objects.

The question is: can I apply a name mapping to an existing dataset while retaining the existing schema?

Desired Solution

We can fetch the mapping itself from an Ampersand script, by extending the INCLUDE statement with a mapping. For that, we need extra syntax in the Ampersand language. The starting point is an existing system with Ampersand script 1, Schema 1, a dataset, and API1 to keep disclosing that dataset in production. Since we don't want to alter API-1, let us put a second one API-2 to access the same dataset but with the new names specified in the mapping. In this way, existing users can continue to use API-1 because it keeps working unaffected by the addition of API-2.

Example

Here is Ampersand script 1:

CONTEXT Script1
RELATION r[A*B]

INTERFACE Overview : "_SESSION"[SESSION] BOX
   [ As : V[SESSION*A] ]
ENDCONTEXT

Here is Ampersand script 2:

CONTEXT Script2
INCLUDE "Script1.adl"
   { CONCEPT A --> X
   , INTERFACE Overview [ As --> Xs ]
   , RELATION r[A*B] --> s
   }

RELATION t[A*B]
ENDCONTEXT

When the user runs Ampersand script 2, she sees an application with the following spec:

CONTEXT Script2

RELATION s[X*B]

INTERFACE Overview : "_SESSION"[SESSION] BOX
   [ Xs : V[SESSION*X ]

RELATION t[A*B]
ENDCONTEXT

Besides, she can run Ampersand script 1 in parallel. She sees that changes in the relation r[A*B] of Ampersand script 1 will appear as changes in relation s[X*B] of Ampersand script 1.

[sjcjoosten]

Script 1 is deployed. Changes to the "data in script 1" (mentioned in the last paragraph of the issue) happen inside a deployment, not in a script. It is unclear to me how script 2 references the particular deployment from which changes should come, I only see it reference a script.

In the full picture, script 2 will also be deployed, so one could argue that the deployment of script 2 is the place to create the reference to the deployment of script 1. If that is the case, script 2 might be sufficient, but then other details are missing and I'd like to see a suggestion for that as well (do we tell this through the API, through an additional file, through environment variables, or something else?)

[stefjoosten]

@sjcjoosten, this issue was written assuming that script 1 and script 2 both refer to the same data set. This assumption comes from the current implementation of the INCLUDE statement, where the including script and the included script both refer to the same data set.

However, I expect the interfaces defined in both scripts to behave differently. If I deploy the interface Script1.Overview, I get to see a field label As and concepts of type A. If I deploy the interface Script2.Overview, I get to see a field label Xs and concepts of type X. The atoms shown by both interfaces remain identical all the time because this is merely about renaming concepts, relations, and interface labels.

[sjcjoosten]

@sjcjoosten, this issue was written assuming that script 1 and script 2 both refer to the same data set.

That is what I understood from the last sentence in the original issue too, which is what raised my questions (which are still left unanswered)