[SHACL API] locating the source of a validation error

[Emmanuel Oga]

Hello,

I have a SHACL validation report. Of course it makes sense the report doesn't mention line and column of the "source" since the triples can come from anywhere (constructed programmatically, from memory, etc. My question is if there's any suggested way to track file and line, perhaps through some implementation detail of a parser (Jena Riot?).

Alternatively I was wondering what's a good pattern to use to display errors under this circumstances. A lot of examples I saw of validations seem to revolve around forms where the components of the triples live in known places, and so the focus node and path could be used to locate the "input field" that caused the problem, but when validating from a source RDF file in some serialization format, is less clear to me how to point to the errors (I guess I go back to needing line and column in a textual buffer).

Thanks!

[Holger Knublauch]

Hi Emmanual,

this would be an awesome feature but I am not aware of an implementation that does what you describe. TopBraid EDG already provides a clickable form-based UI for validation reports, so seeing the Turtle file was never a priority for us. But once someone has written a Turtle writer that remembers the line numbers of each subject (=focus node), predicate and object it would be straight forward to map most violations to a suggested line.

Regards
Holger

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/910cd6f0-ed7a-4850-8b1f-d6fa306e3ebbn%40googlegroups.com.

[Irene Polikoff]

Yes, in EDG, we can run a validation report that goes over entire graph or over all instances of a selected class. All issues are then presented in a report (Problems and Suggestions panel below) and clicking on a given item displays the focus node on a form. For example:

We find that this display format works well.

The use case here is about correcting issues in the graph store in EDG as opposed to fixing the files that were imported. With this, as Holger is saying, referencing line numbers in the source file is not a priority for us.

If one wanted to find triples causing issues in the file, then I think the simplest way right now would be to search for the URI of the focus node in the text.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b7fe0352-3530-b5d9-5078-ac6dd9fef3f1%40topquadrant.com.