{"action":"opened","issue":{"url":"https://api.github.com/repos/BlueBrain/nexus/issues/103","repository_url":"https://api.github.com/repos/BlueBrain/nexus","labels_url":"https://api.github.com/repos/BlueBrain/nexus/issues/103/labels{/name}","comments_url":"https://api.github.com/repos/BlueBrain/nexus/issues/103/comments","events_url":"https://api.github.com/repos/BlueBrain/nexus/issues/103/events","html_url":"https://github.com/BlueBrain/nexus/issues/103","id":367102587,"node_id":"MDU6SXNzdWUzNjcxMDI1ODc=","number":103,"title":"Extend the validation scope for instances","user":{"login":"umbreak","id":1430863,"node_id":"MDQ6VXNlcjE0MzA4NjM=","avatar_url":"https://avatars2.githubusercontent.com/u/1430863?v=4","gravatar_id":"","url":"https://api.github.com/users/umbreak","html_url":"https://github.com/umbreak","followers_url":"https://api.github.com/users/umbreak/followers","following_url":"https://api.github.com/users/umbreak/following{/other_user}","gists_url":"https://api.github.com/users/umbreak/gists{/gist_id}","starred_url":"https://api.github.com/users/umbreak/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/umbreak/subscriptions","organizations_url":"https://api.github.com/users/umbreak/orgs","repos_url":"https://api.github.com/users/umbreak/repos","events_url":"https://api.github.com/users/umbreak/events{/privacy}","received_events_url":"https://api.github.com/users/umbreak/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-10-05T08:05:57Z","updated_at":"2018-10-05T08:05:57Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"From nexus-kg created by [bogdanromanx](https://github.com/bogdanromanx) : BlueBrain/nexus-kg#167  \n\nThe current shacl validation uses a strict model where only the triples of the instance being created or updated are considered. While this behaviour is correct, there is a missed opportunity in checking how the data in the instance relates to other instances in the graph.\r\n\r\nAn example of this would be type checking of linked instances. We can easily picture the need for an instance to link through a predicate to a different instance that is of a specific type:\r\n```\r\nA schema:affiliation B\r\nB rdfs:type schema:Organization\r\n```\r\nIn this example, when we create instance `A` we would like to check that the linked instance (referred in `A`, in our example identified as `B`) has type `schema:Organization`.\r\n\r\nCurrent behaviour:\r\n```\r\n+----------------------+\r\n|Validation Scope      |   +----------+\r\n|                  +-------> Instance +--+\r\n|   +----------+   |   |   +----------+  |  +----------+\r\n|   | Instance +---+   |                 +--> Instance |\r\n|   +----------+   |   |                    +----------+\r\n|                  |   |   +----------+\r\n|                  +-------> Instance |\r\n| +--------+           |   +----------+\r\n| | Schema |           |\r\n| +--------+           |\r\n+----------------------+\r\n```\r\n\r\nProposed behaviour:\r\n```\r\n+--------------------------------------------------------+\r\n|Validation Scope          +----------+                  |\r\n|                  +-------> Instance +--+               |\r\n|   +----------+   |       +----------+  |  +----------+ |\r\n|   | Instance +---+                     +--> Instance | |\r\n|   +----------+   |                        +----------+ |\r\n|                  |       +----------+                  |\r\n|                  +-------> Instance |                  |\r\n| +--------+               +----------+                  |\r\n| | Schema |                                             |\r\n| +--------+                                             |\r\n+--------------------------------------------------------+\r\n```\r\nBased on the constraints defined in the schema we can compute a limited number of additional (existing) instances that can be pulled into the validation scope such that we can perform additional checks on how the newly created or updated instance relates to already existing data.\r\n\r\nSince we cannot afford bringing in the entire graph into the validation scope, the identified instances need to be read from the primary store when creating the validation model. This needs to be limited to the constraints defined in the schema and only up to a certain count and depth (configurable). This restriction is also required by the separation between the write and read models of the service to ensure only reduced availability instead of downtime when the graph store is unavailable.\r\n\r\nChecking the schema for constraints that extend beyond the scope of the validated instance can be done only once when the schema is published to avoid unnecessary computation.\r\n\r\n_Important note_: as linked instances can be independently updated there is no guarantee that the constraints still hold after the creation or update.\r\n\r\nThere is also an additional need of basic reasoning and inference during validation such that the relationships described in the ontology are taken into account. An example of this would be sub-typing. Since the validation scope is fairly small the additional latency caused by this inference should be minimal.\r\n\r\nRelated: #111, #113."}}
{"actor":{"display_login":"umbreak"}}