oparl / validator Goto Github PK

When pressing ctrl+c / ctrl+shift+c in the terminal, the application receives a keyboard interrupt. Most applications stop on the first or second time they receive that signal, but the validator just prints a stacktrace and caries on. Instead, the validator should abort on the first keyboard interrupt

Validators typically send a very recognizable user agent. We should do that too.
Maybe something like

OParlValidator/<version> (https://dev.oparl.org/validator)

I’m getting this error and haven’t been able to find out why. I tried making strict-rfc3339 available to the library but that didn’t fix it.

Unknown type 'date-time' for validator with schema:
...

We already have a docker container for building the specification
available at https://hub.docker.com/r/oparl/specbuilder/. Naturally,
the docker support for the validator should be added to the hub to.

And of course, this implicates that we probably need an automatic update
system for those. Or at least a publicly available schedule on when we'll
update the containers.

Please note that:

• OParl uses JSON-LD
• the expanded examples in the OParl specification draft are not correct (OParl/spec#159)
• the OParl specification does not require using the compacted form

To see the difference between compacted and expanded JSON-LD this playground can be used:
http://json-ld.org/playground/index.html

I therefore suggest to expand JSON-LD first and apply the validation on the result. This library might be helpful: https://github.com/digitalbazaar/pyld

Passing invalid JSON to bin/oparl will result in:

Traceback (most recent call last):
File "bin/oparlval", line 14, in
sys.exit(oparlvalidator.cli.main())
File "/home/ronald/oparl/validator/oparlvalidator/cli.py", line 35, in main
OParl(sys.stdin.read()).validate()
File "/home/ronald/oparl/validator/oparlvalidator/validator.py", line 13, in init
self.data = json.loads(string)
File "/usr/lib/python2.7/json/init.py", line 326, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 365, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 383, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

json.loads() throws an ValueError that isn't handled.

Since no library is perfect, liboparl may occassionally hit a segfault.
This should be caught appropriately and reported to the user.

The validator currently comes to an immediate stop if System.oparlVersion
does not contain a valid version string. This is due to liboparl resolving
the object type based on the validity of this string.

if the system recognizes, that two individuals requested a validation of the same endpoint, it should just do the validation once and send all those who requested a validation of that endpoint the result.

please be aware that the currently running validation should not be taken into account for this pooling-operation. it could be, that a person requests a validation because of a bug that he fixed. in case the current validation has been started before the bugfix on the endpoint has been deployed, the tester may receive misleading results. we should avoid this.

This gives errors that occur repeatedly through backreferences
a higher priority

Requests with HTTP Status 400 could indicate missing or broken links and should
thus be tracked.

Outputting every last bit of information may be too much for some
use cases. Some for of limiting the result output verbosity should be
implemented.

CLI interface proposal is to use the somewhat standard -v{amount}
syntax, i.e. validate -v has a little more output than validate
and validate -vvv will do it's best to flood all the screens.

As I don't expect all vendors to properly implement modified, there should be some way to validate modified, either it as core part of this validator or as external script shipped with the validator.

The tool shall compare an older dump with a new one and check that for every modified object, the modified timestamp has been updated since the last dump. It shall also check that created is a timestamp after the last dump for all newly added objects.

When sending a SIGABRT to a running validator, the output immediately stops as expected but the process keeps on running forever.

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

Eine Möglichkeit zur Prüfung, ob RIS OParl-konforme Daten liefern besteht darin, die JSON-LD Objekte zunächst nach RDF zu konvertieren und dann das RDF-Ergebnis zu prüfen. Damit können prinzipiell zwar vermutlich nicht alle JSON-LD Probleme gefunden werden, aber möglicherweise alle die sich auf die RDF-Ebene auswirken.

Zahlreiche Anregungen dazu gibt es hier:

RDF Validation Workshop
Practical Assurances for Quality RDF Data
10-11 September 2013, Cambridge, MA, USA
http://www.w3.org/2012/12/rdf-val/

Examples of RDF Validation
http://www.w3.org/2012/12/rdf-val/SOTA

Colorama is an unneeded requirement for porcelain mode
and should only be imported if it is actually required.

While information about objects with validation errors is quite useful
in and by itself, System entities contain crucial information needed
to contact vendors and providers related to an OParl endpoint.

When the validator is run as a batch job it may be beneficial to not
have it consume all available system resources. To that end, using
os.nice(<int>) to renice the process to something less cpu demanding
might be a good idea.

Feature suggestion: a webservice API

Ich finde es sehr merkwürdig, dass "-" gewählt wurde um Daten von stdin anzukündigen. Das habe ich bisher bei keinem cli-Tool gesehen und scheint mir sehr uneingängig.

Ich empfehle bei fehlendem Argument von stdin zu lesen.

Und was passiert eigentlich wenn ich von stdin lese? Wird nur das eingegebene JSON geprüft oder werden auch IRIs verfolgt?