[knowledge base] Case-sensitive VAL #7
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alex-mitrevski
requested review from
argenos,
deebuls and
sthoduka
as code owners
|
Nope. I don't think it'll affect at work pipeline. |
sthoduka
approved these changes
Mar 21, 2020
Merged
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR simply prevents VAL from changing the case of domain attributes.
Why is this necessary?
I noticed this was happening while working on b-it-bots/mas_knowledge_base#15. In our ontology, object properties are written in mixed case (following the naming conventions at http://wiki.opensemanticframework.org/index.php/Ontology_Best_Practices). For the export of the ontology to work as expected, the case of the predicates in our domestic planning domain had to be adapted as well; however, after changing the case, I noticed that the names of the predicates are converted to lower case when the domain is parsed (e.g.
defaultStoringLocationtodefaultstoringlocation). This meant that predicate data could not be retrieved afterwards since property assertions are inserted into the knowledge base with the original case of the property name.This problem is avoided by removing the lower case conversion that was done in VAL since predicates keep their original case now.
@DharminB Will your planning pipeline be affected by this change? As far as I can see, you use snake case in the industrial domain, so I don't think it will be, but just to make sure.