Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation query for hasCommunicationAddress #561

Merged
merged 4 commits into from
Sep 14, 2021

Conversation

Jamie-SA
Copy link
Contributor

@Jamie-SA Jamie-SA commented Sep 11, 2021

I was working on queries to validate the new restrictions on various changes made in this release but after working on them a bit I realized that these types of checks would be better to do in SHACL. If OntoTool can do SHACL validation as part of the migration process I could create some shapes to enforce the new restrictions. Shapes could also be added later.

This PR has a couple of queries that can be included.

@Jamie-SA Jamie-SA changed the base branch from develop to basic-migration September 11, 2021 04:44
@Jamie-SA Jamie-SA requested a review from sa-bpelakh September 11, 2021 04:44
Copy link
Collaborator

@sa-bpelakh sa-bpelakh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

onto-tool can handle SHACL on local execution (see https://github.com/semanticarts/gist/blob/develop/bundle.yaml#L59), but since there is no uniform way to invoke SHACL across different triple stores, there is no support for endpoint SHACL validation. For that reason I have gone with SPARQL for the migration, so that the queries can be reused.

Good catch not assuming that triple store queries the union of all named graphs, I need to add a version of my detect query that looks inside graphs.

I would simplify the detection query as follows:

CONSTRUCT {
    ?report a sh:ValidationReport ;
        sh:conforms false ;
        sh:result
            [
                a sh:ValidationResult ;
                sh:focusNode ?failedEntity ;
                sh:resultMessage "Domain restriction on gist:hasCommunicationAddress violated" ;
                sh:resultSeverity sh:Warning ;
                sh:sourceConstraintComponent <urn:constraint:communicatonAddress-domain>
            ] .
}
WHERE {
    { ?failedEntity gist:hasCommunicationAddress ?addr . }
    FILTER NOT EXISTS {
        { ?failedEntity a gist:Person } UNION { ?failedEntity a gist:Organization }
    }
    bind(<urn:new-domain-validation-report> as ?report)
}

There is no reason to include the URI in the error message, since it's automatically included in the report as the focusNode.

Since the detection queries are run via the following section of the script, if you prefix the file names with detect_, you won't need to make any additional changes.

- action: "verify"
  message: "Find remaining problems"
  type: "construct"
  inference: "none"
  stopOnFail: false
  target: '{report}'
  endpoint:
    query_uri: "{endpoint}"
    user: "{user}"
    password: "{password}"
  queries:
    source: '{migration}/v10.0'
    includes:
      - 'detect_*.rq'

@Jamie-SA Jamie-SA requested a review from sa-bpelakh September 13, 2021 20:29
@sa-bpelakh sa-bpelakh merged commit b594d48 into basic-migration Sep 14, 2021
@sa-bpelakh sa-bpelakh deleted the migration_hasCommunicationAddress branch September 14, 2021 02:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants