Discuss the JSON schema

[kltm]

Once we have a draft schema in place from #277, we need to hammer out the "final" schema that we'll be using for the ShEx transformation into useful products for applications.

[tmushayahama]

just a quick thought @sierra-moxon @cmungall after yesterday's discussion about the schema, I realized the array/list might have minor performance issues because it is no longer a dict lookup and the consumer needs to do a search/find algorithms. an example below. However, if it is not a quick change schema, no worries,

1) The lookup type id always a key

This one getting a specific relation is a simple lookup O(1)

 "relationships": {
    "rel1": {
      "medatada": ...,
    },
    "rel2": {
      "metadata": ...,
   }
}

getRelationship(rel) {
    return relationships[rel]
}

**2) List needs searching the whole list O(n) to find and prune to duplicate ids **

 "relationships": [
    {
      "id": "rel1",
     "medatada": ...,
    },   {
     "id": "rel2",
     "medatada": ...,
    },
]

getRelationship(rel) {
   for (let i = 0; i < relationships.length; i++) {
      if (rel === relationshps[i].id) {
          return relationships[i];
       }
    }
}

It might be a tiny loop, but the 2 way binding of client its been called multiple times

[kltm]

For "1" and "2", I would expect that the UI logic could unwind any data structure to a constant time lookup on load. I don't think the list is that long in the first place; I would be surprised if there was a lag there that a user would notice either way. Is this something you've noticed?

[tmushayahama]

@kltm it hits hard. Unfortunately, it is not onLoad, but per binding lifecycle and since it is a form, it cycles a lot (textChange, blur, focus etc) . Preferably binding to constant lookup is desirable if possible than binding to function
So everytime we want to display 'part_of' metadata we just get the value straight up

<p>{{MFnode.relationships['part_of'].metadata}}</>

Than do a loop
<p>{{getRelationships(MFNode, 'part_of').metadata}}</>

Then now it's for every relation and it refreshes per lifecycle detect changes.

[kltm]

Ah, that's interesting, and a bit nasty--too bad. Can you make global data structures in this case to take care of this overhead as the JSON should be invariant?