Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve ShEx error messages #70

Open
labra opened this issue Apr 26, 2020 · 4 comments
Open

Improve ShEx error messages #70

labra opened this issue Apr 26, 2020 · 4 comments

Comments

@labra
Copy link
Member

labra commented Apr 26, 2020

The information of error messages is incomprehensible for an end user. See this issue about SHaclEX.

Providing a better error information system for ShEx can be a challenge given ShEx expressivity that can make it difficult to guess which is the root cause of the error. However, for some (most) of the shapes, it should be easier.

The strategy to improve this issue will probably involve several steps:

  • Refactor the library to separate the natural language messages from the error messages. Right now, the error messages are created from natural language messages by hand which is not very elegant. It would be much better to define an upper class for ShExError and define different sub-classes for the different cases. Later, we could try to re-generate the natural language representation of those classes. An added benefit is that we could even generate localized error messages in different languages. We have already started with this refactoring but it was left unfinished.

  • Identify classes of shapes features which can provide better error messages. For example, some shapes which have no repeated properties can provide more intuitive error messages. We also started this process by defining Flat shapes which are shapes that have no repeated properties. Error messages for these shapes could provide much more informative information.

This issue will be divided in several issues and remain open until we consider that the error messages are more comprehensible.

@ericprud
Copy link

ericprud commented Apr 26, 2020

I claimed in a shexjava issue that ShEx folks were interested in standardizing error reports (as much as practical). I know @hsolbrig was interested. Where does this land in your priority stack?

@labra
Copy link
Member Author

labra commented Apr 27, 2020

I am very interested and you guessed well that the problem was with my priority stack.

I am finishing my teaching duties on 19th May, since them I can devote more time to this.

Meanwhile, these weeks I am cleaning the validation code and tackle the first part of the issue, i.e. generate machine-readable errors instead of natural language ones.

@henrietteharmse
Copy link

Any update on this issue? Is there perhaps a planned due date or suggested alternative approach?

@labra
Copy link
Member Author

labra commented Mar 15, 2022

Thanks for your interest...we have been working on some aspects of this, bit I admit that there is a lot of space for improvement.

One aspect we improved it a little bit is that now the error messages can be shown in either natural language or JSON, and the JSON representation contains information about the line/column numbers of the nodes and shapes that have failed.

The shex-s library contains a command line interface that you can use with an option to select which result format you want, which can be either JSON or a Result ShapeMap with information in natural language.

We gave more priority in the last months to add support to extends, a new feature that increases ShEx expressivity. Now that our implementation passes all the tests, we are more confident to refactor it and in fact we have already started to do it and create a new validator which I hope will also improve the error messages.

I'm afraid we don't have a planned due date for this because we are currently doing this without proper funding and more as part of our research tasks. Anyway, as we have other projects that indirectly are funding this one, we will continue advancing in this direction.

Of course, if you have specific examples or suggestions for imprvements, let us know so we can give them more priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants