AQL: Path+Archetype ID in RESULT_SET.columns

Specifications AQL
1

Hi all,

I have mentioned in the last SEC meeting the need of adding some archetype_id information in the columns because the paths alone are not enough info to know what the data in the row columns are.

So for instance, in EHRBASE we have something like:

{
    "q": "SELECT o, eval, i FROM EHR e[...] contains composition c contains observation o[...]
    OR evaluation eval[...] OR instruction i[...]",
    "columns": [
        {
            "path": "/",
            "name": "#0"
        },
        {
            "path": "/",
            "name": "#1"
        },
        {
            "path": "/",
            "name": "#2"
        }
    ],
    "rows": [
        [

Clients actually need to know the query projections to process the result correctly, because all the columns have path /

My proposal was to add to archetype id since the path is relative to the archetype root, these are different ways of doing the same:

  1. absolute path:
"columns": [
    {
        "path": "openEHR-EHR-OBSERVATION.../",
        "name": "#0"
    },
    {
        "path": "openEHR-EHR-EVALUATION.../",
        "name": "#1"
    },
    {
        "path": "openEHR-EHR-INSTRUCTION.../",
        "name": "#2"
    }
  1. archetype_id and path:
"columns": [
    {
        "archetype_id": "openEHR-EHR-OBSERVATION",
        "path": "/",
        "name": "#0"
    },
    {
        "archetype_id": "openEHR-EHR-EVALUATION",
        "path": "/",
        "name": "#1"
    },
    {
        "archetype_id": "openEHR-EHR-INSTRUCTION",
        "path": "/",
        "name": "#2"
    }
  1. archetype_id, variable and path:
"columns": [
    {
        "o": "openEHR-EHR-OBSERVATION",
        "path": "o/",
        "name": "#0"
    },
    {
        "evail": "openEHR-EHR-EVALUATION",
        "path": "eval/",
        "name": "#1"
    },
    {
        "i": "openEHR-EHR-INSTRUCTION",
        "path": "i/",
        "name": "#2"
    }

Which do you think would be the best proposal?

2

I vote for 3) since this path identification is only valid in the context of interpreting a query result and I would also drop the trailing ‘/’ which doesn’t bring any additional information as compared to the query formulation.

1 Like
3

I cannot understand why this is needed. The aliases o, eval, i are typed, in the sense that we know column “o” will have observations. So we know what the data in the columns are.
Care to explain what the problem is a bit more?

4

I also don’t understand the problem yet. Perhaps @pablo, you could give better real-file examples, or at lest something more illustrative.
If the problem is clear, then we could focus on solution.

1 Like