Encoding problem with ICV errors in Java

Support Bug
1

Here is what I’m getting:

VIOLATED bruker:Innsynskrav rdfs:subClassOf ((bruker:forsendelsesmåte only bruker:Forsendelsesmåte) and (bruker:forsendelsesmåte exactly 1 bruker:Forsendelsesmåte))
   ASSERTED <http://data.einnsyn.no/innsynskrav/a691c082-ecd3-492b-b261-a2d7117d7a86> a bruker:Innsynskrav
   NOT_INFERRED <http://data.einnsyn.no/innsynskrav/a691c082-ecd3-492b-b261-a2d7117d7a86> bruker:forsendelsesmåte <tag:stardog:api:variable:x0>
                <tag:stardog:api:variable:x0> a bruker:Forsendelsesmåte

I was expectng Ã¥ to be å.

On 4.3.2 btw.

2

Looks like a UTF-8 encoding issue. You might want to check the encoding on the source data. Are you running on windows or using virtual graphs?

3

Looks like it's and example of Treating UTF-8 Bytes as Windows-1252 or ISO-8859-1

4

I’m afraid I think the encoding issue is somewhere in the stardog sesame library.

5

I’m running 4.2.1 on Linux and it appears to return that character correctly. (I only tested a select query not stardog reasoning explain). You haven’t mentioned if you’re running windows or not but what format did you import your ontology from? What encoding is it using? Turtle is required to be encoded in UTF-8.

6

Zachary. This encoding issue is only visible with ICV constraint violations printed from the exceptions in java.

Håvard

7

So this is from the Stardog logs?

8

Hey guys,

I actually just found at least one of the places this is happening, and it seems to be a client issue, rather than the server. I’m looking into workarounds for it and also trying to patch it up in all the places it appears.

9

Well, good news and bad news. The good news is that I have found exactly where this is happening, and it will be fixed in an upcoming release. The bad news is that I don't believe there's a workaround that can be used until then.

I can confirm that the problem is in the stardog HTTP client, where the default ISO-8859-1 encoding is mistakenly being used. What this means, however, is that if you use the HTTP API directly (e.g., http://localhost:5820/myDb/icv/validate) UTF-8 can be specified for decoding the response from the Stardog server.

10

Thanks for figuring this out Stephen :slight_smile: Glad it’ll be fixed in the next
release, I also ran into HTTP Client’s archaic encoding defaults the other
day.

I’m already using regex to match the icv failures, so I’ve just modified
that to wildcard the special characters.

Does Stardog have any plans to expose the ICV failure message in Java as
something more structured than a string?

11

If you're talking about a Java API, we have an example in our examples repo that details how to get structured Proof objects from the Stardog server

12

Thanks Stephen,

Just got to find out how to use this to parse the exception that .commit() is throwing.

Håvard