For reasons that I believe have to do with additional data not changing already inferred facts (AKA monotonicity), certain OWL constructs MUST be expressed as a blank node. I think it's a great idea to remove blank notes wherever possible in wikidata but if you want the data to be conformant with OWL (and thus work in e.g. Protégé, OWLAPI, and some other tools), I believe you are stick using blank nodes for some OWL expressions.

I'll weigh in on 341 after we reach consensus here on whether our (Andra, Labra, DanBri, myself, ...) interpretation is correct that, at least for http://www.wikidata.org/entity/Q313093.ttl , a blank node represents the unknown value in https://www.wikidata.org/wiki/Q313093#Q313093$761f04ee-4d7f-d725-522a-85a3077bb47b . (Perhaps Andra can speak to "no value" cases.)

Oops, sorry, I failed to notice that.

I don't believe it's the same. T244341: Stop using blank nodes for encoding SomeValue and OWL constraints in WDQS is about the use of blank nodes in the representation of some OWL expressions. The OWL spec is very clear about saying that they have to be blank nodes so the decision was made by the OWL Working Group 15 years ago.

I believe Blaze supports the RDF4J API. @Jelabra , is that your understanding?
At any rate, every graph store has a fast and efficient getTriplesMatching(s, null, null) function, which is all we need.

ShEx schemas have an RDF representation. which round-trips everything except comments and whitespaces. For example, compare 3circRefPlus1.shex to 3circRefPlus1.ttl or 1dotIMPORT1dot.shex to 1dotIMPORT1dot.ttl in https://github.com/shexSpec/shexTest/tree/master/schemas.

The RDF model asserts that a literal with a langtag is considered to have a datatype of rdf:langString. The various formats state exactly how literals with langtags are written. The former specifies how APIs behave, such as a SPARQL FILTER DATATYPE("ab"@es) = rdf:langTag; the latter specifies that it's written {"type":"literal", "value":"ab", "xml:lang":"es"}. The rules for the XML and JSON results formats are that the implicit datatype of langtagged literals is omitted.

That's way cooler than mine. @Jelabra, can that be plugged in today?

The schema for human advertises both the entities which should pass and ones that should fail. This sort of QC can help keep the schemas themselves testable and more reliable over time and many editors.

I mocked up using the ace ShExC mode in an EntitySchema.

You might not want to add it to the data itself as people persuing different use cases will want to assert that the item is linked to different schemas. When I go to test whether a schema matches <SomeSpecialWidget>, I won't be interested in whether it matches everything else it's ever been used for, so at the very least, properties linking data to schemas are advisory and not required for the validation infrastructure.

I believe that removing the results section makes it basically impossible to diagnose errors.
I added a switch ?ui=full to enable the results section and the control menu. You can see it in use in a video. Does the behavior without that switch close this issue?

propose adding E12345 to the list 'cause it's not uncommon to have to model three interconnected schemas and E123{,4{,5}} is a nice mnemonic for a scratch space for that.
other than that, +1 to calling this done.