Local and endpoint migration for renamed and removed entities. #554
Conversation
| } UNION { | ||
| ?oldClass ?defProp ?defObj | ||
| } | ||
| } |
There was a problem hiding this comment.
Why do we have both action_rename_classes.rq and action_rename_classes_default.rq and similarly for properties?
There was a problem hiding this comment.
We do renaming in two steps:
- First rename everything that is in a named graph, retaining the modified triples in their original graphs, and then
- Rename all that is remaining, which would be in the default graph
We do it in this manner because the default graph does not have a universally recognized reference URI, and in some triple stores it doesn't have a URI at all. Also, when processing local file data, there are no named graphs, so only the default queries (which don't specify a graph) are used.
There was a problem hiding this comment.
A local .trig or N-quads file can have named graphs. I assume that works correctly for them as well.
There was a problem hiding this comment.
@Jamie-SA There is no current support in onto-tool for .trig or .nq inputs. Do you view this as a deal breaker for this functionality? There is no way I can code and test this before Monday
There was a problem hiding this comment.
It is not a deal breaker for me, I had assumed the library you use to read/write would support all of the main formats. But if not, I wouldn't hold this up because of it.
I have switched almost entirely to .trig because of it's support for named graphs.
There was a problem hiding this comment.
The toolkit (rdflib) does support it, but I have not enabled it - and there is an existing issue (semanticarts/ontology-toolkit#65), to which I will give some attention after this release.
migration/v10.0/detect_removed.rq
Outdated
| } | ||
| } | ||
| } | ||
| bind(<urn:deleted-entity-vaidation-report> as ?report) |
There was a problem hiding this comment.
Minor typo:
| bind(<urn:deleted-entity-vaidation-report> as ?report) | |
| bind(<urn:deleted-entity-validation-report> as ?report) |
docs/MajorVersionMigration.md
Outdated
| # Major Version Migration | ||
|
|
||
| When non-backward compatible changes are introduced into `gist` during major upgrades, | ||
| developers will create queries that attempt to migrate existing ontologies and data to |
There was a problem hiding this comment.
Instead of "developers will create queries that attempt to migrate..." how about "the release package will include queries to facilitate the migration of existing ontologies and date to conform to the new version of gist."
My reasoning here is that "try to" sounds like we're not sure. Where we have scripts that do the migration, we're sure that they work.
|
Thanks @sa-bpelakh and @rjyounes . @rjyounes , waiting on your final approval to merge and seal the release. |
|
@rjyounes Adjusted documentation as per your suggestions |
…ddress Validation query for hasCommunicationAddress
This is in anticipation of #535, based on the most recent version.
In order to run these, you will need to make sure that onto-tool is upgraded to v1.4.1.
I ran the local migration using the following command:
which updates all
.ttland.owlfiles in theinputdirectory (not recursively, is that an issue?) and places the updated RDF in theoutputdirectory. ValidationReport RDF is placed in thereportdirectory.To run the migration against a SPARQL endpoint:
For databases where the UPDATE endpoint is different, it can be provided via
-v update_endpoint URIin addition to the query endpoint provided via-v endpoint.Do we want to include detailed documentation for the migration in the release notes of each major release, since users will not have access to our Confluence pages?