Author: Agent

SAREF4CITY & SAREF4INMA Join Smart Data Models: 35 Candidate Models for Smart Cities and Manufacturing

  By ,

Smart Data Models’ Candidates repository now includes two more ETSI SAREF extensions: saref4city and saref4inma, together contributing 35 candidate models. Both ship the full Candidates artifact set — a JSON Schema, an NGSI-LD @context, and all four example serializations — validated against its own schema.

SAREF4CITY — 14 models

SAREF4CITY (ETSI TS 103 410-4, Oct 2024) is aimed at city administrations and smart-city platform builders who need a common, IoT-friendly vocabulary instead of yet another bespoke city data schema. It handles the “one KPI, many measurements” problem distinctly well: a general KPI definition (e.g. “road congestion”) is kept separate from its individual timestamped  ssessments, so historical values accumulate cleanly under one stable definition. It also gives city topology (countries → cities → districts → neighbourhoods, spatially linked via GeoSPARQL) a reusable shape, and models public services with who provides them, who uses them, where, and in what languages — directly reusing the EU’s own ISA² Core Public Service Vocabulary rather than reinventing it.

Category Models
Topology / geo AdministrativeArea, CityObject, Facility, plus City, Country, District, Neighbourhood
Agents & organizations Agent, PublicAdministration
Events & accessibility Event, AccessibilityConcept
KPIs KeyPerformanceIndicator, KeyPerformanceIndicatorAssessment
Services PublicService

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4city

SAREF4INMA — 21 models

SAREF4INMA (ETSI TS 103 410-5) targets factory operators, equipment vendors, and supply-chain software vendors who need to trace a manufactured item back to the exact production equipment, batch, raw material, and timestamp that produced it — both inside the factory and after the item has shipped. It gives semantic interoperability between heterogeneous  roduction-equipment vendors and a standard vocabulary for item/batch/material traceability, aligned with Industry 4.0 reference architectures and IEC 62264’s factory/site/area/work-center location model.

Category Models
Identifier hierarchy ID, GTIN8ID, GTIN12ID, GTIN13ID, GTIN14ID, IRDI, UUID
Products / materials Item, ItemBatch, ItemCategory, MaterialBatch, MaterialCategory, Batch, Size
Production equipment ProductionEquipment, ProductionEquipmentCategory, ProductionEquipmentFunction
Factory/location hierarchy Factory, Site, Area, WorkCenter

All 21 examples are drawn from, and cross-consistent with, the single worked “shaver manufacturing” scenario in the ETSI spec’s own clause 4.3 — so a reader can trace one shaver’s full genealogy across every model.

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4inma

Translation notes

  • Inheritance flattened, not duplicated. SAREF4CITY’s four AdministrativeArea subclasses (City, Country, District, Neighbourhood) and SAREF4INMA’s identifier subclasses (GTIN8ID…UUID → ID, WorkCenter → ProductionEquipment) inherit everything and add nothing of their own — each still gets its own candidate model, documenting what it inherits in its description rather than repeating properties, following the precedent set by this repo’s Gaia-X candidate.
  • A documentation/ontology discrepancy, resolved transparently. ETSI TS 103 410-4’s own property table omits refersToFeature from KeyPerformanceIndicatorAssessment, but the published .ttl and the spec’s own figures both include it — the .ttl was treated as authoritative and the property included, with the discrepancy noted in standard-metadata.yaml.
  • Six near-duplicate identifier relationships simplified. SAREF4INMA’s hasGTIN8ID/hasGTIN12ID/…/hasUUID convenience sub-properties were consolidated into one generic hasIdentifier relationship, documented as a simplification.
  • License recorded exactly as found, not guessed — SAREF4INMA’sdct:license points to ETSI’s own forge software license.

Try it, and tell us what’s missing

These are Candidates — first, carefully-sourced translations, not yet promoted to official Smart Data Models subjects. Overlap with existing official subjects hasn’t been checked in detail, and license terms for the specific v2.1.1 releases should be confirmed before promotion.

Browse the models, open an issue, or send a PR:
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4city
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4inma

SAREF4AGRI & SAREF4AUTO Join Smart Data Models: 58 Candidate Models for Precision Agriculture and Connected Vehicles

  By ,

Smart Data Models’ Candidates repository now includes two more ETSI SAREF extensions: saref4agri and saref4auto, together contributing 58 candidate models. Both ship
the full Candidates artifact set — a JSON Schema, an NGSI-LD @context, and all four example serializations — validated against its own schema.

SAREF4AGRI — 21 models

SAREF4AGRI (ETSI TS 103 410-6) extends SAREF into precision agriculture and livestock monitoring, stitching together W3C SSN/SOSA (systems, platforms, deployments), GeoSPARQL (farm and parcel topology), the TIME ontology (deployment periods), OBO TAXRANK (species classification), and FOAF (farmers and farm holdings as organizations). It’s grounded in two worked examples in the standard: a livestock farm with milking and eating-activity sensors, and a smart-irrigation deployment with soil tensiometers and pluviometers reporting through a platform/system/deployment chain.

Category Models
Features of interest / topology Animal, AnimalGroup, Crop, Soil, Parcel, Farm
People / organizations Farmer, FarmHolding
Infrastructure Platform, Deployment
Smart-irrigation sensors/actuators Pluviometer, SoilTensiometer, WeatherStation, WateringGun, WateringSystem, WateringValve, Thermometer
Livestock-farming sensors MovementActivitySensor, EatingActivitySensor, MilkingSensor, WeightSensor

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4agri

SAREF4AUTO — 37 models

SAREF4AUTO (ETSI TS 103 410-7) is SAREF’s extension for connected and automated vehicles and the roadside infrastructure (C-ITS) that supports them — vehicles, trailers, dangerous-goods cargo, vehicle platoons, pedestrians/cyclists and their clusters, parking spots, roadside units/sensors/actuators/traffic lights, traffic management centres, and a wide catalogue of sensor types (lidar, radar, UWB, stereovision…).

Category Models
Core automotive entities AutomotiveEntity, TrafficParticipant, Vehicle, Trailer, DangerousGoods
Platooning Platoon, PlatoonJoin, PlatoonBreakup, PlatoonLeave
Vulnerable road users VulnerableRoadUser, VRUCluster, ClusterJoin, ClusterBreakup, ClusterLeave
Roadside infrastructure AutomotiveDevice, RoadSideEquipment, RoadSideUnit, RoadSideActuator, TrafficLightController, RoadSideSensor, TrafficManagementCentre
Traffic events & parking TrafficEventObservation, TrafficEventCause, ParkingSpot
Sensors 13 types, e.g. LidarSensor, RadarSensor, StereovisionSensor, UwbSensor

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4auto

Translation notes

  • Large named-individual vocabularies, kept open rather than exploded. SAREF4AUTO’s 161-member TrafficEventCause vocabulary (drawn from ETSI’s ITS Common Data Dictionary) became one entity with an open causeCode and a closed category enum of the 20 top-level causes — not ~160 separate models. Similarly, ~30 vehicle kinds, ~20 dangerous-goods kinds, and VRU profile/sub-profile vocabularies were folded into enum-valued attributes on their owning entity.
  • Generic value-wrapper classes excluded. Eight SAREF4AUTO OWL “typing” classes with no domain content of their own (BooleanProperty, DecimalProperty, ConfidenceValue…) aren’t modeled as entities — every property using them is instead a plain typed attribute on its owning entity. Net effect: ~46 raw primary classes in scope → 37 genuinely distinct models.
  • Road topology deliberately excluded. SAREF4AUTO’s own Road/ RoadSegment/Lane classes were left out of this translation, since they would duplicate rather than extend the official dataModel.Transportation subject’s existing coverage.
  • Two naming collisions found, kept verbatim. SAREF4AUTO’s own Vehicle (C-ITS/kinematics-oriented: heading, speed, automation level) and ParkingSpot (thinner, C-ITS-oriented) share a name with existing official Smart Data Models that cover complementary but non-identical ground (fleet/telematics Vehicle; richer occupancy-model ParkingSpot). SAREF4AGRI’s Animal likewise shares a name with the official dataModel.Agrifood‘s own Animal. Per the translation policy, names were kept exactly as the source ontologies define them rather than renamed to dodge the collision — flagged in each standard’s standard-metadata.yaml for the Candidates review process to resolve.

Try it, and tell us what’s missing

These are Candidates — first, carefully-sourced translations, not yet
promoted to official Smart Data Models subjects. The naming collisions
above are the main open item for both standards before promotion.

Browse the models, open an issue, or send a PR:
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4agri
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4auto

SAREF4EHAW & SAREF4WEAR Join Smart Data Models: 41 Candidate Models for eHealth and Wearables

  By ,

Smart Data Models’ Candidates repository now includes two more ETSI SAREF extensions, both from the health and personal-devices space: saref4ehaw and saref4wear, together
contributing 41 candidate models. Both ship the full Candidates artifact set — a JSON Schema, an NGSI-LD @context, and all four example serializations — validated against its own schema.

SAREF4EHAW — 21 models

SAREF4EHAW (ETSI TS 103 410-8) is SAREF’s extension for eHealth and “ageing well” / active assisted living — the vocabulary behind remote health monitoring setups like a patient wearing a Body Area Network (BAN) of sensors, actuators, and wearables that funnel vital signs through a BAN hub to caregivers.

Category Models
Actors HealthActor, Caregiver, Helper, User, Patient, ResponsibleParty
Activity Activity, DailyActivity, NocturnalActivity
Body Area Network Ban, BanApplicationTask, BanHub
Devices HealthDevice, HealthActuator, HealthSensor, HealthWearable, FunctionalDevice
Communication CommunicationInterface, CommunicationNetwork, CommunicationProtocol
Observation ObservationCollectionExecution

A good chunk of this extension is pure specialization with no new properties of its own — DailyActivity, HealthSensor, HealthActuator, HealthWearable, BanHub, Patient, and ResponsibleParty all inherit everything from a richer parent class, and each candidate’s description explains exactly what it inherits rather than inventing properties that don’t exist in the ontology.

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4ehaw

SAREF4WEAR — 20 models

SAREF4WEAR (ETSI TS 103 410-9) covers wearable technology more broadly — smartwatches, fitness bands, implantable health monitors, smart textiles, even crowd-control badges used by event staff. Devices are classified by how they relate to the body (in-body, on-body, near-body, textile/fabric-integrated), linked to the “Wearer” they’re attached to, and described by the functions they perform (communicating, controlling, navigating, notifying) and the hardware components they’re built from.

Category Models
Wearable-device family WearableDevice, InBodyWearable, OnBodyWearable, NearBodyWearable, TextileBasedWearable, FabricWearable
Actors / features of interest Wearer, User, LivingOrganism, Software
Hardware components Interface, PowerSupply, MemoryStorage, TextileBasedSensor
Functions CommunicatingFunction, ControllingFunction, NavigatingFunction, NotifyingFunction
Governance & events Policy, Occurrence

The example data (a Garmin-style heart-rate monitor on a runner, an implanted glucose-style monitor, a crowd-control wearable detecting a restroom queue at a music festival) is drawn directly from the worked scenarios in the normative ETSI specification.

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4wear

Translation notes

  • Property-grouping classes flattened into plain attributes. Both ontologies classify measurable quantities (heart rate, battery level, air quality, soil moisture-style readings) using abstract grouping classes with no properties of their own, populated only by a handful of named individuals. Rather than mirroring that grouping hierarchy as
    thin extra entities, each named individual became a directly-named attribute on the device/wearer that carries it (e.g. WearableDevice.batteryRemainingTime, Wearer.heartRate) — the ontologies’ own documentation explicitly endorses this as an open, non-exhaustive vocabulary rather than a closed enumeration.
  • TTL vs. normative-PDF discrepancies, documented rather than silently resolved. SAREF4EHAW’s PDF tables several properties (hasHabit, hasInterface, availableFlash…) with explicit domains that aren’t actually declared in the published .ttl; SAREF4WEAR has a comparable gap (wearerRangeAge in the PDF vs. wearerAgeRange in the .ttl). Every such gap is flagged plainly in the affected property’s
    schema description and in standard-metadata.yaml, with the .ttl
    treated as authoritative.
  • One real naming collision found. Smart Data Models’ own dataModel.Hl7 already publishes a Patient model (the full FHIR resource). SAREF4EHAW’s Patient is a much narrower concept — a thin, zero-own-property “cared-for person” — kept under its own name per the translation policy, with the collision flagged for reconciliation before promotion out of Candidates.
  • Privacy-conscious examples. Given the personal-health subject matter, every SAREF4EHAW example uses clearly synthetic, non-identifying placeholder data.

Try it, and tell us what’s missing

These are Candidates — first, carefully-sourced translations, not yet promoted to official Smart Data Models subjects. The Patient naming collision above is the main open item before promotion.

Browse the models, open an issue, or send a PR:
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4ehaw

👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4wear

SAREF4WATR & SAREF4GRID Join Smart Data Models: 89 Candidate Models for Water and Smart Grid Metering

  By ,

Smart Data Models’ Candidates repository now includes two more ETSI SAREF extensions, both built around smart metering: saref4watr and saref4grid, together contributing
89 candidate models — the largest pair in this translation round. Both ship the full Candidates artifact set — a JSON Schema, an NGSI-LD @context, and all four example serializations — validated against its own schema.

SAREF4WATR — 49 models

SAREF4WATR (ETSI TS 103 410-10) spans the entire water domain: natural water bodies (rivers, lakes, aquifers, glaciers), the infrastructure that moves and treats water (distribution systems, treatment plants, gauging stations, hydroelectric plants), individual field assets (pipes, valves, pumps, fire hydrants, manholes), and smart water meters with their tariff models.

Category Models
Natural water bodies Water, Aquifer, Estuary, Glacier, Lagoon, Lake, Ocean, River, Sea
Water infrastructure DistributionSystem, StorageInfrastructure, MonitoringInfrastructure, TreatmentPlant, HydroelectricPowerPlant, GaugingStation
Assets — transport/storage/devices Channel, Intake, Main, Manhole, Pipe, Pit, Vent, Tank, Reservoir, FireHydrant, Pump, Valve, WaterMeter
Meter/tariff model Tariff, ConsumptionBasedTariff, ThresholdBasedTariff, TimeBasedTariff
Property-grouping / controlled-vocabulary AcceptabilityProperty, BacterialProperty, ChemicalProperty, MicrobialProperty, WaterFlowProperty, WaterUse

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4watr

SAREF4GRID — 40 models

SAREF4GRID (ETSI TS 103 410-12) is SAREF’s extension for smart electricity metering, explicitly designed to mirror DLMS/COSEM (IEC 62056) so its classes map cleanly onto real meter data — every COSEM object carries an OBIS code (hasObis), the same identifier engineers use on the wire. It spans the physical meter and its components, tariff/billing automation, generic COSEM data capture, and a full remote read/write/action service stack.

Category Models
Device & device management GridMeter, Firmware, NetworkInterface, Clock, BreakerState
Tariff/billing automation ActivityCalendar, SeasonProfile, DayProfile, ScriptTable, Script
Data capture ProfileGeneric
Power-line / meter property kinds EnergyAndPowerProperty, QualityProperty, MeterProperty, PowerLine
COSEM remote services & operations GetService, SetService, ActionService, plus 16 related operation/input/output models

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4grid

Translation notes

  • Measurable quantities kept as open vocabularies, not exploded into entities. Both standards express specific measurable properties (water quality parameters, ActiveEnergy, Voltage, Current, ReactivePower…) as named individuals of a handful of grouping classes rather than as classes in their own right. Each group class was
    modeled once, with an enum closed to its own named-individual set (plus a broaderPropertyType/taxonomic field where the source ontology defines a broader/narrower relationship) — giving full fidelity to every named individual without near-duplicate entity types.
  • DLMS/COSEM alignment preserved. SAREF4GRID’s OBIS-coding convention is carried through to the candidate schemas via hasObis, keeping the translation directly usable against real meter data rather than an abstraction that loses the wire-level identifier.
  • Inheritance flattened, not duplicated, following this repo’s established Gaia-X precedent — SAREF4WATR’s deep taxonomy of water-body and asset “kinds” each still gets its own candidate model, documenting its taxonomic role rather than repeating inherited properties.
  • No naming collisions found against existing official Smart Data Models subjects for SAREF4GRID; SAREF4WATR’s Water entity does conceptually overlap with the already-published WaterQualityObserved model — flagged, not resolved, for reviewers to reconcile at promotion time.

Try it, and tell us what’s missing

These are Candidates — first, carefully-sourced translations, not yet promoted to official Smart Data Models subjects. The Water / WaterQualityObserved overlap above is the main open item before promotion.

Browse the models, open an issue, or send a PR:

https://github.com/smart-data-models/Candidates/tree/master/standards/saref4watr
https://github.com/smart-data-models/Candidates/tree/master/standards/saref4grid

SAREF4ENER & SAREF4ENVI Join Smart Data Models: 116 Candidate Models for Energy Flexibility and Environment

  By ,

Smart Data Models’ Candidates repository now includes two new candidate standards translated from ETSI’s SAREF (“Smart Applications REFerence”) ontology family: saref4ener and saref4envi, together contributing 116 candidate models. Both are official ETSI Technical Specifications, each with a normative PDF and a published Turtle/JSON-LD/RDF-XML ontology, and both ship the full Candidates artifact set — a JSON Schema, an NGSI-LD @context, and all four example serializations (NGSI-v2 and NGSI-LD, key-values and normalized) — validated against its own schema.

SAREF4ENER — 61 models

SAREF4ENER (ETSI TS 103 410-1) is the SAREF extension for energy flexibility and demand-response: the vocabulary behind smart appliances, batteries, and loads that can shift or modulate their power consumption in response to grid signals or incentives. It covers seven distinct “flexibility profile” shapes (power-envelope, power-limit, fill-rate, incentive-table, demand-driven, operation-mode…), the request/offer/instruction messages exchanged between a flexibility provider and a grid operator, load-control events and states, and the generic data-point/time-series building blocks used throughout.

Category Models Examples
Flexibility profiles & elements 14 PowerEnvelopeProfile, FillRateProfile, IncentiveTableProfile, OperationModeProfile
Instructions (one per profile type) 10 OMBCInstruction, FRBCInstruction, PEBCInstruction, DDBCInstruction
Flexibility communication 3 FlexRequest, FlexOffer, FlexibilityInstruction
Load control 4 LoadControlEventData, LoadControlStateData, LoadControlEventAction
Power/energy constraints & limits 8 PowerConstraint, PowerLimit, FailsafePowerLimit, ContractualPowerLimit
Data & scheduling 7 DataPoint, TimeSeries, GaussianDataPoint, Slot, Timer
Core & other 15 Device, Storage, PowerSequence, Role, Incentive

Branch: saref4ener-candidates — PR not yet opened.

SAREF4ENVI — 55 models

SAREF4ENVI (ETSI TS 103 410-2)
covers two distinct worlds under one ontology: a lighting/light-pollution domain (lampposts, light points, illuminance/sky-brightness observations) and a full waste-management lifecycle — from a resident’s bin, through collection rounds, to treatment, disposal, and the emissions and secondary resources that treatment produces.

Category Models Examples
Buildings/urban 9 Building, City, Neighbourhood, CollectionOfBuildings
Waste treatment devices 14 Composter, AnaerobicDigester, IncineratorWithRecovery, Sorter
Collection 6 CollectionPoint, Depot, Itinerary, WasteCollectionVehicle
Treatment tasks & functions 8 WasteTreatmentTask, WasteDisposalFunction
Lighting 4 Light, LightPoint, Lamppost, ShieldedLamppost
Waste core / resources / emissions 11 Waste, FinalWaste, Resource, Emission
General 3 DigitalRepresentation, CommunicationInterface, CommunicationProtocol

A rich object-property graph (accepts, isProducedBy, isDepositedIn, becomes, followsItinerary…) is translated throughout as NGSI-LD Relationships between these models.

Branch: saref4envi-candidates — PR not yet opened.

Translation notes

  • Open vocabularies stay open. Both ontologies lean heavily on abstract “Kind” classification classes (WasteKind, ContainerKind, EmissionKind…) whose members are a small, fixed vocabulary rather than independently-instantiable things. Rather than creating dozens of near-empty entity types, these were folded into open/enumerated string attributes on the entities that actually reference them (e.g. Container.acceptedWasteKinds, Emission.emissionKind).
  • Names preserved verbatim. SAREF4ENVI’s own class and property names were already PascalCase/camelCase and needed zero renaming. SAREF4ENER’s profile/instruction naming (OMBCInstruction, FRBCInstruction, …) is kept exactly as the ontology defines it.
  • Inheritance flattened, not duplicated. Following the precedent set by this repo’s Gaia-X candidate, a subclass’s schema lists only its own attributes; inherited ones are documented in its description instead of repeated (e.g. SAREF4ENVI’s House/NonResidentialBuilding point back to Building/Perimeter).
  • License recorded exactly as found. Both ontologies’ dcterms:license resolves to ETSI’s own software license terms (BSD-3-Clause for SAREF4ENVI) — recorded in each standard’s standard-metadata.yaml for confirmation before promotion out of Candidates.

Try it, and tell us what’s missing

These are Candidates — first, carefully-sourced translations, not yet promoted to official Smart Data Models subjects. A few things are open and would benefit from community input before that step: license confirmation for the specific v2.1.1 releases, and a check for overlap with existing official subjects (dataModel.Device, dataModel.Environment,
dataModel.WasteManagement-adjacent models).

Browse the models, open an issue, or send a PR:
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4ener
👉 https://github.com/smart-data-models/Candidates/tree/master/standards/saref4envi

New pysmartdatamodels Version 0.8.2.0: Semantic Identification for Data Spaces

  By , , , , , , , , , , , ,

We are happy to announce a new release of our Python package, pysmartdatamodels, version 0.8.2.0. The headline feature is aimed squarely at data spaces: a new function that can give semantic meaning to a payload even when the party who sent it never provided one.

What’s New in This Version?

Semantic identification for data spaces: identify_or_draft_datamodel()

In a data space, you routinely receive payloads from other participants with no guarantee they follow any particular standard. identify_or_draft_datamodel() takes any such payload and does one of two things:

  • If it recognizes the payload as an existing Smart Data Model, it returns that model’s real schema, together with a full validation of the payload against it.
  • If it doesn’t, it drafts a brand new schema.json on the spot — following the same structural conventions as a real Smart Data Model — so you have a ready-to-review starting point instead of nothing at all.

It accepts the payload in any of the three formats actually used in practice — plain key-values, NGSI-v2 normalized, or NGSI-LD normalized — detecting and handling the right one automatically:

from pysmartdatamodels import pysmartdatamodels as sdm

payload = {
    "id": "urn:ngsi-ld:WeatherObserved:station-042",
    "type": "WeatherObserved",
    "temperature": 21.5,
    "relativeHumidity": 0.6
}

result = sdm.identify_or_draft_datamodel(payload)
print(result["schema"]["source"])   # "existing" -- it recognized WeatherObserved
print(result["schema"]["validation"]["result"])  # True

When the payload’s own “type” doesn’t match anything, you can optionally ask it to try a softer, attribute-based match against the whole catalog before giving up and drafting a new schema:

result = sdm.identify_or_draft_datamodel(payload, fuzzy=True, fuzzy_threshold=0.3)

And when nothing matches at all, the drafted schema isn’t just a bare shape guess — any attribute whose name is already established elsewhere in the catalog (over 160,000 attribute definitions) gets its real description, model reference, and units reused automatically, so only genuinely new attributes are left with a plain TODO placeholder.

A real validate_payload()

validate_payload(datamodel, subject, payload) existed before but didn’t actually validate anything. It now runs full JSON Schema validation against the live schema of the data model you name, confirms the payload’s “type” matches, and separately flags – without failing – any attribute that isn’t part of the official definition.

Reliability and performance fixes

  • generate_sql_schema() no longer crashes on attributes that can hold more than one type (e.g. a Property that can also be a Relationship), and no longer generates colliding enum type names when two unrelated models happen to share an attribute name.
  • validate_data_model_schema() no longer terminates your entire Python process on a bad input — it returns an error result like every other function in the package.
  • The ~160,000-entry attribute database is now cached in memory instead of being re-read from disk on every single function call — noticeably faster for any code calling the per-attribute lookup functions in a loop.

Get the Latest Version

Update your installation with:

pip install --upgrade pysmartdatamodels

➔️ Get the package on PyPI

New pysmartdatamodels Version 0.8.1.0: Refreshed Data (reduced size 20 times with same functionality)

  By , , , , , , , , , , , ,

We are happy to announce a new release of our Python package, pysmartdatamodels, version 0.8.1.0, with a refreshed attribute database, a smaller download, and a cleanup of some leftover dead code.

What’s New in This Version?

Refreshed Data, End to End

The package’s bundled data — the official list of data models, the attribute metadata, and the full attribute database — had gone stale. Fixing this surfaced two real issues in our own publication pipeline, now resolved:

  • One data model repository had accidentally been left private, which was silently breaking the daily metadata regeneration every time it ran.
  • The database backing the attribute export (see below) was far less complete than it should have been. It’s now fully backfilled: 164,926 attribute records across all 82 subjects.

As always, you don’t need to upgrade the package just to get fresh data — calling update_data() pulls the latest information directly:

from pysmartdatamodels import pysmartdatamodels as sdm
sdm.update_data()

Smaller Install, Compressed Attribute Database

The full attribute database is now shipped gzip-compressed inside the package (~5MB instead of ~110MB) — the installed package footprint drops from over 100MB to under 10MB. This is fully transparent if you use the documented functions (load_all_attributes(), description_attribute(), etc.) — nothing changes in how you call them.

The same compressed file is now also available for direct download, alongside the existing uncompressed one, from the attribute database export page.

Cleanup

Removed a small piece of dead code in generate_sql_schema() left over from an earlier implementation — no change in behavior, just a cleaner function. Thanks to the community member who originally reported it.

Get the Latest Version

Update your installation with:

pip install --upgrade pysmartdatamodels

➡️ Get the package on PyPI

New pysmartdatamodels Version 0.8.0.11: More Reliable SQL Schema Generation

  By , , , , , , , , , , , ,

We are happy to announce a new release of our Python package, pysmartdatamodels, version 0.8.0.11, focused on making the SQL schema generation function more robust, fixing how the package exposes its functions, and keeping our GitHub source and published package in sync.

What’s New in This Version?

More Reliable SQL Schema Generation

The generate_sql_schema() function, which turns a data model’s model.yaml into a ready-to-use PostgreSQL CREATE TABLE statement, received three fixes:

  • Column names are now properly quoted, so attribute names that are reserved words or mixed case no longer produce invalid SQL.
  • Properties using anyOf are now supported, in addition to oneOf.
  • The function no longer emits a duplicate id column in the generated schema.

Example:

from pysmartdatamodels import pysmartdatamodels as sdm

sql = sdm.generate_sql_schema("https://raw.githubusercontent.com/smart-data-models/dataModel.Weather/master/WeatherForecast/model.yaml")
print(sql)

More Usable Imports

You can now import the package’s main functions directly from the top level, instead of always going through the submodule:

from pysmartdatamodels import generate_sql_schema, load_all_datamodels

The documented usage pattern below continues to work exactly as before:

from pysmartdatamodels import pysmartdatamodels as sdm

Repository Housekeeping

The source code published on GitHub and the package published on PyPI had drifted apart over the last few releases. With this version, both are back in sync, so what you see in the repository is exactly what you get when you pip install the package.

Get the Latest Version

Update your installation with:

pip install --upgrade pysmartdatamodels

➡️ Get the package on PyPI

Our Commitment to Open and Interoperable Data

We are committed to making data interoperability easier for everyone. Thanks to everyone in the community who reports issues and helps us keep improving pysmartdatamodels!

New candidate models: SIMPLE’s Business Service extensions to FEDeRATED

  By

Nine new candidate data models are now available in the Smart Data Models Candidates repository, covering business transactions and logistics services for road and rail freight, translated from the SIMPLE project’s extensions to the FEDeRATED Business Service ontology.

The models cover the full lifecycle of a freight movement: Consignment and Shipment (with delivery time windows and an eFTI UID for EU-Gate interoperability), TransportService and CargoHandlingService, and five order types used at cargo terminals — CargoHandlingOrder, DischargeOrder, GateInOrder, GateOutOrder and ShuntingOrder.

These models are grounded in the ontology published at vocab.plataformasimple.es and its imported FEDeRATED Business Service base ontology, with each entity’s schema reflecting the full set of inherited attributes — including required fields drawn directly from the base ontology’s own cardinality constraints.

Explore the models: standards/simple-federated-businessservice in the Candidates repository.

New candidate model: SIMPLE’s Digital Twin extension to FEDeRATED (CMR)

  By

A new candidate data model is now available in the Smart Data Models Candidates repository: CMR, the international road freight consignment note (“carta de porte”), translated from the SIMPLE project’s extension to the FEDeRATED Digital Twin ontology.

CMR documents are the standard legal paperwork accompanying road freight shipments across most of Europe. The model captures its identifying attributes (document ID, version, type, MRN number) and external identifiers, ready to be linked from a business transaction.

Explore the model: standards/simple-federated-digitaltwin in the Candidates repository.