fix!: fix valueHasUri bad values and missing types (DEV-1036)

[mpro7]

PR Checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

Issue Number: DEV-1036

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[mpro7]

@subotic this isn't breaking change, because it's just plugin to fix bad data. There will be no major version increase, therefore ontology version wasn't updated too. I checked locally test-repository-upgrade is taking new plugin into the consideration, but on the LS maybe it will need to be started manually?

[subotic]

1. did you check, if the standoff handling actually requires or can handle typed values? The value at line 29 is a correct IRI in pointy brackets. You could check it by for example changing existing test data and then running the tests (if this case is covered).

2. Also, did you check if the existing test data needs to be changed?

[mpro7]

I don't know how/where to check but in LS data there are only 2 instances of data written like in the code snippet above. Any other valueHasUri used in standoff looks like that:

knora-base:valueHasUri          "https://lumieres.unil.ch/fiches/bio/2666/"^^xsd:anyURI .

In our test data I found only one example which is typed string:
https://github.com/dasch-swiss/dsp-api/blob/main/test_data/all_data/anything-data.ttl#L1244

[subotic]

Suggested change

	val newObjectValue = nodeFactory.makeDatatypeLiteral(literal.value, OntologyConstants.Xsd.Uri)

[mpro7]

Thanks for suggestion, but it needs to take parameter because in another case it takes differently named value to create DatatypeLiteral.

[subotic]

@subotic this isn't breaking change, because it's just plugin to fix bad data. There will be no major version increase, therefore ontology version wasn't updated too. I checked locally test-repository-upgrade is taking new plugin into the consideration, but on the LS maybe it will need to be started manually?

@mpro7 AFAIK there is no way of running the upgrade scripts manually. So the only way is to bump the ontology version number, which then necessitates to bump the mayor number of DSP-API. I think that at some point I said, that each time an upgrade script needs to be run it is seen as a breaking change, because without the upgrade script, the system is broken, which is exactly the state in which we are now. Also, we define what breaking change means. It serves a purpose. In this case, it should scream at the person who is deploying: "look at the logs to see if the upgrade went through without problems" and "this time deployment will take longer than usual".

[irinaschubert]

LGTM, just some cosmetic suggestions. I would also recommend to double check if it works with standoff (but Ivan already mentioned that).

[mpro7]

@subotic I thought it is possible to run scripts on servers so this could be run like that - manually. but if you say so I changed it to be the breaking change and updated version numbers.

[BalduinLandolt]

LGTM

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication