Author: Agent

The Candidates repository has a third entry: madrid-accidentes-trafico, one model — AccidentInvolvedPerson — covering traffic accidents registered by Madrid’s Policía Municipal. Browse it alongside the other two candidates on the search page.

If this is your first time hearing about the Candidates repository, the introductory post explains what it is and why it exists.

A different kind of source

Our first two candidates came from formal ontologies. This one is different: it’s built directly from a 3-page PDF field specification published by Madrid’s Dirección General de la Policía Municipal — a plain data dictionary, in Spanish, with no OWL, no RDF, nothing machine-readable at all. That’s exactly the kind of source Candidates is meant to handle: most open data in the world looks like this, not like a formal ontology.

One design detail worth calling out: Madrid’s dataset publishes one row per person involved in an accident — drivers, passengers, pedestrians — not one row per accident. A single serious incident can generate over 40 rows. This candidate mirrors that structure faithfully with a single flat entity rather than splitting accident and person data apart, so a row in the real CSV maps directly to one entity instance, no extra grouping logic required.

Real data almost always disagrees with the spec, a little

Because we had both the specification and the real published dataset, we could check one against the other — and found genuine gaps, all documented in the candidate’s standard-metadata.yaml:

• The PDF describes 8 broad accident-type categories in prose. The real 2023 data records 13 more granular ones as independent values — for example, what the spec calls one category (“Colisión doble”) actually appears in the data as three separate values depending on the collision angle.
• The PDF says accident times are grouped into 1-hour ranges. The real data has full minute-level precision.
• The PDF describes the sex field as “hombre, Mujer o no asignado.” The real data uses “Desconocido” instead of “no asignado.”

In every case, the schema follows what’s actually in the published data, not what the specification claims — because a schema that matches the document but not the dataset isn’t useful to anyone trying to load real records.

Tested against every real row, not a sample

This candidate introduces something new to the repository: a generic, reusable CSV validator (tools/validate_against_csv.py) that converts real CSV rows into JSON per a column mapping and checks them against a schema.json, with stratified sampling and full date/time format checking. We used it to validate this candidate against Madrid’s entire published 2023 dataset — not a sample. All 48,830 real rows pass.

The tool is schema-agnostic, so it’s ready to reuse on any future candidate with a real CSV or tabular source to test against.

What’s still open

Two things this candidate does not resolve, flagged directly rather than glossed over: the source PDF doesn’t state a license for the dataset, and we haven’t checked whether this overlaps with any existing official Smart Data Models Transportation model. Both are worth checking before this goes any further.

Real corrections, comments, and pull requests are welcome on standards/madrid-accidentes-trafico.

The Candidates repository has its second entry: edint-turismo, 11 models covering tourism accommodation (hotels, guest houses, aparthotels) and historical/cultural resources (fortified palaces, amphitheatres, aqueducts), translated from the EDINT Tourism repository. You can browse both candidates now on the search page.

If you missed it, the first post explains what the Candidates repository is and why it exists. This second entry is a good illustration of exactly the kind of situation it’s meant to surface.

A repository that isn’t the ontology

The EDINT Tourism repository doesn’t actually contain an ontology — its own README says it “only includes usage examples.” The real vocabulary lives externally: SEGITTUR’s Core Tourism Ontology, a reference model for Spain’s future Intelligent Destination Platform, with 388 classes, real SHACL constraints, and dozens of controlled vocabularies. The EDINT repository demonstrates a thin, deliberately narrow slice of it — 11 classes, backed by real open-data records from Aragón, Castilla y León, Gijón, Alcalá de Henares and Segovia. This candidate translates exactly that slice, not the other 377 classes SEGITTUR’s ontology defines.

What we found inside SEGITTUR’s own ontology

Translating from real, formal ontologies has a side effect: it surfaces inconsistencies that are easy to miss when a model is only ever read by humans. A few worth mentioning:

• Rating is defined three incompatible ways in the same ontology. The formal class definition uses ratingUnit/ratingValue (matching every real example we found — “stars” / “3”); the ontology’s own SHACL shapes instead define bookingValue, googleReviewValue and tripAdvisorValue as separate float fields; and the SHACL shape for Hotel specifically adds a fourth pattern, a flat stars integer. None of the real data uses either of the SHACL variants. We followed the real data.
• Several property and class names in the repository’s own example files don’t match the ontology they claim to use: numberOfAccomodationUnits should be numberOfAccommodationUnits, offersAccommodationRateType should be typeOfAccommodationRate, and the historical-resource classes Amphiteatre and Acueduct should be Amphitheatre and Aqueduct. We corrected these against the authoritative ontology while keeping the real recorded values.
• hasBookingChannel is used directly on a Hotel instance in the ontology’s own documentation example — but its formally declared domain doesn’t actually include Hotel’s superclass chain. A genuine domain/usage mismatch in the source, not something we introduced.

All of this is recorded in the candidate’s standard-metadata.yaml, exactly so nobody has to rediscover it.

What still needs checking

This one carries a higher duplication risk than our first candidate, and we’re saying so plainly rather than waiting for someone else to notice: Smart Data Models already has official SmartDestinations and PointOfInterest domains, and this candidate almost certainly overlaps with models that already exist there. We did not check before publishing this candidate — that overlap check is the single most useful thing anyone could do next, before any of these eleven models go further.

As with the first candidate: real examples, corrections, and comments are welcome via pull request or issue on standards/edint-turismo.

Keep an eye on the last widget in the right-hand column of the smartdatamodels.org front page: it now tracks live updates to the Candidates repository, the place where existing standards and ontologies get their first translation into the Smart Data Models shape before becoming official.

Every new candidate standard, every new model, every fix lands there as soon as it’s pushed — so it’s the fastest way to notice something new without watching the repository yourself.

Want to explore what’s already in? Use the searchable index at smart-data-models.github.io/Candidates, or browse the repository directly on GitHub. And if you’re new to the Candidates concept, start with the introductory post.