The 13 things this service asks an endpoint. Each carries its own verdict and none is combined with another into a score: there is no ranking on this site, and these are the reasons why one would be misleading.
Answers a trivial query
dimension: availability cost: cheap
Whether a query reaches the endpoint and comes back. The probe is one SELECT for a single triple, which is the smallest question a SPARQL endpoint can be asked, so a failure here is about reaching the service rather than about anything in its data. A timeout is indeterminate and never absent: what was observed is that no answer arrived inside the budget, which is not the same as an endpoint that answered and had nothing.
Sends access-control-allow-origin on a simple GET
dimension: interoperability cost: cheap
Whether a script in a browser could read this endpoint's answer. This is what a curl user sees: the header on a plain GET. It is deliberately separate from the preflight below, because an endpoint can have one and not the other and neither implies the other.
Answers a CORS preflight for a cross-origin GET
dimension: interoperability cost: cheap
Whether a browser would even attempt a real query. Before sending a cross-origin request that is not simple, a browser asks the target for permission with an OPTIONS request naming the method and headers it intends to use, and sends nothing if the answer does not allow them. That question is the preflight, and it is what decides whether an in-page query editor can talk to this endpoint at all. The probe records the header VALUES and not just their presence, because a header that is there and says no is not permission.
GeoSPARQL relation functions
dimension: capability cost: cheap
Whether the engine evaluates GeoSPARQL relation functions, asked with a filter over constants so the answer is about the engine rather than about the data. This is the metric where the vocabulary earns its keep: an endpoint can evaluate these functions without declaring them, which is undeclared but verified, and an endpoint can answer a point-in-polygon test with the wrong answer, which is declared but wrong. Both are true of real endpoints in this registry.
Holds WKT geometry
dimension: content cost: cheap
Whether any geometry is actually stored, asked separately from the functions above because holding geometry and being able to reason over it are different facts. The probe guards against a literal that is present and empty, because one endpoint in the survey this project reproduces passed a naive check while every geometry it held was nil.
Service description informativeness
dimension: documentation cost: cheap
What the endpoint says about itself when asked with no query at all. Graded rather than yes or no, because a description that exists and names nothing useful is not the same as one that names its dataset, its graphs and the languages it supports. Most of the descriptions in this registry are at the lowest level, which is the engine's default stub rather than anything a publisher wrote.
States how many triples it holds
dimension: content cost: expensive
How many triples the endpoint says it holds, in void:triples, set against a count of them. A description that is a few percent out is still 'verified': a VoID file is written once and the dataset keeps growing, so calling that wrong would be crying wolf on nearly every real endpoint. An order of magnitude out reads 'declared but incorrect', which is the most useful thing this service can tell a consumer about a description. The count unions the default and named graphs, because the default-graph-only form answered 0 against a store holding 12.5 million triples across 45 named graphs, measured 2026-09-05.
States how many graphs it holds
dimension: content cost: expensive
How many named graphs the endpoint says it has, against a count of them. No VoID or service-description term states a NUMBER of graphs, so the claim is the length of the sd:namedGraph list, which means an endpoint listing none reads as declaring none rather than as declaring zero.
States how many classes it holds
dimension: content cost: expensive
How many distinct classes the endpoint says it holds, in void:classes, against a count of them. Distinct from 'describes its own vocabulary', which asks WHICH classes were named rather than how many: an endpoint can state the right number and name none of them.
Describes its own vocabulary
dimension: content cost: cheap
Whether the endpoint's own description names the classes it actually holds. The class profile pass finds what is there; a VoID class partition is how a publisher says what should be there; this is the two set against each other. 'Confirmed, not declared' is the common reading and not a fault in the data: an endpoint can hold hundreds of classes and describe none of them, which is exactly the gap this service exists to measure. It reads 'not determined' wherever the profile pass did not run, which at the default cheap ceiling is everywhere, because there is nothing to set the description against. It never reports a description as WRONG: the class enumeration is capped and the profile pass samples, so a declared class missing from the profiles may simply never have been asked about, and that is not evidence enough for the harshest verdict in the vocabulary.
Properties per class
dimension: content cost: expensive
For each class the endpoint holds, which properties its instances carry, how many instances carry each one, and whether the values are IRIs or one datatype or several. This is the question the content metrics were reaching for and could not answer: 'holds typed resources' and 'distinct classes' both reported that a query came back, while this reports what is in there. The most expensive thing this service does to a stranger's server, at one query per class, so it is declined at the default cheap ceiling and a sweep has to ask for it. It publishes no verdict, because a profile is a description and not a judgement: there is no threshold at which 'this class has four properties' is a pass or a failure.
Holds typed resources
dimension: content cost: cheap retired: 2026-08-28
Whether anything in the endpoint carried a type at all, asked with one row as the whole answer. No longer measured, because the question it answered was not the one it looked like: every RDF dataset worth monitoring has types, so as a fact about CONTENT this was close to worthless, and 54 verified against 489 indeterminate on the 2026-08-24 sweep says what it was really reporting was whether a query came back. Availability asks that, with a smaller query. Measurements already taken are still shown and still true of the sweep that took them.
Distinct classes
dimension: content cost: expensive retired: 2026-09-04
Which types the endpoint holds, sampled rather than counted. No longer measured as a verdict, and it never produced one: it is expensive, every sweep so far ran at the cheap ceiling, and all 597 of its mentions across the preserved runs are declines. A 'verified' here would have meant only 'we enumerated some classes', which is the same near-worthless fact that retired 'holds typed resources'. The question itself was worth asking, so its query survives as the first step of 'properties per class' below, which publishes the class list as a sample instead of a judgement. Declines already recorded are still shown and still true of the sweep that recorded them.
The label, the dimension and the cost class are
prober/metrics.toml's own values and a test fails when this
page and that file disagree. A cheap metric runs on every sweep; an
expensive one runs only when a sweep is told it may, and is otherwise
recorded as declined rather than as a zero.