Category: Cross Sector

UNTP Digital Product Passport Joins Smart Data Models: Two new candidate models — DigitalProductPassport and Product

  By

Smart Data Models’ Candidates repository now includes a new candidate standard, untp-v0.8.0, translated from the UN Transparency Protocol (UNTP) Digital Product Passport specification — a B2B data standard, issued as a W3C Verifiable Credential, for carrying product and sustainability information through supply chains. Two entities are covered: DigitalProductPassport and Product.

What’s in it

Model What it is
DigitalProductPassport The W3C Verifiable Credential (VCDM 2.0) envelope: issuer, validity period, credential status, render method, issuing software.
Product The core product data model: identification, classification, material provenance, producing facility, dimensions, packaging, performance claims, and an open industry-specific characteristics extension point.

Every model ships the full set of Candidates artifacts: a JSON Schema, an NGSI-LD @context, and all four example serializations (NGSI-v2 and NGSI-LD, key-values and normalized) — each validated against its own schema.

Two entities, one relationship — not one flattened blob

In the source, DigitalProductPassport.json‘s credentialSubject is literally $ref: "#/$defs/Product" — a 1:1 inline embedding. But Product.json is also published standalone, with its own complete identity independent of any credential wrapper. This candidate keeps that distinction: DigitalProductPassport carries only the envelope fields plus a product Relationship, and Product is its own separately-addressable entity — avoiding a ~20-property duplication and matching how the source itself chose to publish two files, not one.

The VC envelope fields (issuer DID, credential status, render method, issuing software) are modeled faithfully as real typed properties rather than simplified away — even though they’re strictly artifacts of the credential-verification layer, not “product data” per se.

Real context, real examples — not invented

Two things set this translation apart from working off prose docs alone:

  • A genuine published JSON-LD context. UNTP ships a complete, ~106KB context file using JSON-LD type-scoped contexts. This candidate’s context.jsonld IRIs are extracted from that real file — with two scope-collision bugs caught and hand-corrected along the way (a naive flatten of a type-scoped context can silently grab a same-named term from an unrelated class; here it briefly mapped the envelope’s validFrom to an unrelated ConformityProfile field, and the new product Relationship to an unrelated Digital Traceability Event term, before being fixed).
  • Real sample data. Both example.json files are drawn from UNTP’s own published sample instance — a 75 kWh Li-ion EV battery pack passport, complete with real material provenance (cobalt from DRC, lithium from Chile, nickel from Indonesia, …) and EU Battery Regulation performance claims — not fabricated placeholder values.

One naming fix was needed: the source’s own @context property (the W3C VC context array) would collide with NGSI-LD’s reserved top-level @context mechanism, so it’s renamed to vcContext — the same pattern already used for a dataProvider collision in the Gaia-X candidate.

Note on scope

Per explicit instruction, only these two entities are covered. UNTP defines several other credential types this specification references — Digital Conformity Credential, Digital Facility Record, Digital Traceability Event, Digital Identity Anchor — none of which are modeled here. Fields that reference them (e.g. producedAtFacility, a claim’s evidence links) stay exactly as the source declares them, not promoted to Relationships pointing at not-yet-modeled entity types.

Try it, and tell us what’s missing

This is a Candidate — a first, carefully-sourced translation, not yet promoted to an official Smart Data Models subject. Before that step:

  • License terms haven’t been confirmed against the spec-untp repository’s own LICENSE file yet.
  • Overlap with other Smart Data Models product/traceability vocabularies hasn’t been checked in detail.

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

Gaia-X Ontology Joins Smart Data Models: 165 Candidate Models for Cloud, Connectivity & Trust

  By

Smart Data Models’ Candidates repository now includes a new candidate standard, gaiax-ontology-v2111, translated from the Gaia-X ontology v2111 — the vocabulary behind Self-Descriptions in Gaia-X federated data spaces and cloud ecosystems. All 165 classes published at docs.gaia-x.eu/ontology/v2111/classes now have an NGSI-LD / NGSI-v2 representation.

What’s in it

Gaia-X’s ontology is broader than a typical device/observation vocabulary — it describes both the physical/technical side of an offering and the legal/governance claims attached to it. That split shows up directly in the model mix:

Category Models Examples
Legal & governance documents 50 LegalDocument, TermsAndConditions, DataUsageAgreement, ServiceAgreementOffer
Compute & software 27 CPU, GPU, Memory, Hypervisor, ComputeFunctionRuntime, Image
Security 25 Encryption, PhysicalSecurity, InformationSecurityPolicies, ProductSecurity
Network 23 Endpoint, VLANConfiguration, InterconnectionServiceOffering, PointOfPresence
Infrastructure 19 Datacenter, AvailabilityZone, Region, PhysicalResource
Service offerings 17 ServiceOffering, ComputeServiceOffering, StorageServiceOffering
QoS metrics 13 Latency, Jitter, PacketLoss, Throughput, IOPS
Storage 13 BlockStorageConfiguration, ReplicationPolicy, SnapshotPolicy
Data products 13 DataProduct, DataProductCatalogue, EvidenceTemplate
Trust framework 10 Ecosystem, EcoTrustScope, EcoTSP, CompliantCredential
+ identifiers, measurement, FaaS, environmental, and more ~19 VatID, EORI, EnergyMix, WaterUsageEffectiveness

Every model ships the full set of Candidates artifacts: a JSON Schema, an NGSI-LD @context, and all four example serializations (NGSI-v2 and NGSI-LD, key-values and normalized) — each validated against its own schema.

Translation notes

  • Names preserved verbatim. Gaia-X’s own class and property names (hasPoint-style camelCase, PascalCase classes) are kept exactly as the ontology defines them — no forced renaming.
  • Cross-references become NGSI-LD Relationships. Any property whose range is another Gaia-X class (e.g. Datacenter.aggregationOfResources → AvailabilityZone) is modeled as a Relationship, not an inlined object, so the resulting graph mirrors the ontology’s own linking structure.
  • Inheritance is flattened, not duplicated in text. A subclass’s schema only lists its own properties; inherited ones are documented on the parent model and referenced by name in the description, matching how the source ontology itself organizes properties.
  • Open vocabularies stay open. A number of Gaia-X properties reference controlled vocabularies (e.g. DiskType, HypervisorType) that aren’t enumerated on the class documentation pages themselves; those are modeled as open strings with a note in the description rather than an invented closed enum.
  • One naming collision, resolved explicitly. DataUsageAgreement‘s own dataProvider property (the participant providing a Data Product) would collide with the Candidates convention’s boilerplate dataProvider metadata field (harmonised-data-entity provider). It’s exposed as gxDataProvider instead, with the substitution documented in the schema’s own description.

Try it, and tell us what’s missing

This is a Candidate — a first, carefully-sourced translation, not yet promoted to an official Smart Data Models subject. A few things are open and would benefit from community input before that step:

  • Overlap with existing Smart Data Models subjects (dataModel.Device, generic infrastructure/building vocabularies) hasn’t been checked in detail.
  • License terms for the specific v2111 release should be confirmed before promotion out of Candidates.
  • A handful of controlled vocabularies referenced by the ontology (e.g. disk/hypervisor/firmware type enumerations) aren’t resolved to closed lists yet — see the individual schema descriptions for which ones.

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

Introducing the Smart Data Models Candidates Repository

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

The Smart Data Models now has a Candidates repository — a low-friction entry point where any existing standard, ontology or open dataset can be translated into the SDM shape (JSON Schema + NGSI-LD context + examples) before anyone commits to the full contribution process. The first entry, translated from the EDINT Infrastructure Ontology, is live today — and it needs your help to move forward.

What is the Candidates repository?

Until now, turning an external standard into a Smart Data Model meant going almost straight to the Incubated repository, where a contributor actively develops the model to the point of passing our full validation suite and preparing it for official publication. That’s the right process once someone is committed to doing the work — but it leaves no room for a lighter step: “here is a standard that looks like it maps well onto NGSI-LD — does anyone want to develop this further?”

The Candidates repository fills that gap. It maps existing standards — ontologies, open data schemas, sector vocabularies — into the SDM format (JSON Schema, JSON-LD context, key-value and NGSI-LD normalized examples) as a starting point, organized standard-first:

standards/<standard-slug>/
  standard-metadata.yaml
  models/<EntityName>/
    schema.json
    context.jsonld
    examples/
      example.json
      example-normalized.jsonld

A candidate is not a finished data model. It’s a proposal: a structurally valid, plausible translation that any user of Smart Data Models can pick up, test against real payloads, comment on, correct, or use as the basis for a full contribution to Incubated.

The first example: the EDINT Infrastructure Ontology

The first entry, edint-infraestructura, translates the EDINT Infrastructure Ontology — a formal OWL vocabulary developed under the EU-funded EDINT (Espacio de Datos para las Infraestructuras Urbanas Inteligentes) project for describing a municipality’s public and private facilities: educational, cultural, social and sports centers, health centers, on-street and off-street parking, and shared-bicycle stations, together with the sensors, observations, management roles and organizations involved in operating them.

Eleven candidate models were generated: Facility, Parking, BikeSharingStation, ObservationPoint, AccessSensor, CountingSensor, AccessObservation, CountingObservation, Violation, ManagementRole and Organization. Every schema is valid JSON Schema (Draft 2020-12) and every example validates against its own schema — but that’s where “finished” stops. In the spirit of being upfront about what a Candidate actually is, here’s exactly where this one stands:

  • Real examples exist for only one of the eleven models. Facility is grounded in a real record from the source ontology’s own example data (a municipal day-care center in Madrid). The other ten — the sensors, observations, violations, roles — have plausible but synthetic example payloads, because the source ontology itself doesn’t ship real instance data for them. This is the single most useful thing the community could contribute right now: real payloads from an actual access-control sensor, a real counting observation, a real management-role record.
  • Two models likely duplicate existing official subjects. Parking and Organization are thin, attribute-free specializations in the source ontology and may well overlap with the existing official dataModel.Parking and dataModel.Organization. This needs a real review before either goes any further.
  • The source ontology is licensed CC-BY-SA-4.0 (ShareAlike), while SDM contributions are conventionally CC-BY-4.0. This hasn’t been resolved and is flagged directly in the candidate’s standard-metadata.yaml for whoever picks this up next.
  • Geolocation needs a second look. The source ontology’s geometry is expressed in a projected coordinate system (not WGS84), so the example coordinates here are illustrative Madrid locations, not verified reprojections of the original data.

None of this makes the candidate useless — quite the opposite. It’s exactly the kind of concrete, checkable list that turns “someone should look into this standard” into a set of small, tractable tasks anyone can pick up.

How a Candidate could become an official data model

There is no formal graduation process yet, and we’d rather propose one in the open than invent it quietly. Here’s a first draft, and we’re actively looking for feedback on it:

  1. Real-world evidence. At least one model in the candidate has real, non-synthetic example payloads from an actual system or dataset using it.
  2. Passes validation. The candidate’s schemas and examples pass the standard SDM test suite with zero blocking failures (the same 12 checks used for Incubated contributions).
  3. No unresolved duplication. Any overlap with an existing official model has been explicitly checked and either resolved (extend the existing model instead) or justified (the candidate covers something genuinely different).
  4. Compatible licensing. The source material’s license allows redistribution under the terms Smart Data Models publishes under.
  5. A short public review. A brief comment period on the candidate’s pull request or a linked issue, open to anyone in the community.

Once a candidate clears these, it moves into the normal Incubated workflow for full development ahead of official publication.

How to get involved

  • Browse the repository: github.com/smart-data-models/Candidates
  • Search all candidates: smart-data-models.github.io/Candidates — a searchable, always up to date index of every candidate standard and model
  • Contribute a real example for any of the eleven EDINT models above — open a pull request against standards/edint-infraestructura/, or an issue if you’re not sure how.
  • Propose a new candidate: if you know a standard, ontology or open dataset that should have an SDM mapping, open an issue describing it, or submit the translated standards/<slug>/ folder directly.
  • Give feedback on the promotion criteria above — they’re a first draft, not a final decision.

Find all published Smart Data Models at smartdatamodels.org/ search menu, and everything currently in development in the Incubated repository.

New data models OSMBoundary, OSMClub, OSMCraft, OSMEmergency, OSMGeological, OSMHealthcare, OSMHistoric, OSMIndoor, OSMManMade, OSMMilitary, OSMOffice, OSMPlace, OSMPower, OSMRoute, OSMTelecom, OSMTrafficSign and OSMWater at subject dataModel.OpenStreetMap

  By

We are pleased to announce the publication of OSMBoundary, OSMClub,  OSMCraft,  OSMEmergency,  OSMGeological, OSMHealthcare, OSMHistoric, OSMIndoor, OSMManMade, OSMMilitary, OSMOffice, OSMPlace, OSMPower, OSMRoute, OSMTelecom, OSMTrafficSign and OSMWater within the subject dataModel.OpenStreetMap.

OSMBoundary: Administrative and other boundaries from OpenStreetMap tagged with boundary=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMClub: Social, sports, or interest-based clubs from OpenStreetMap tagged with club=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMCraft: A place for crafts and manual trades from OpenStreetMap tagged with craft=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMEmergency: An emergency facility or equipment from OpenStreetMap tagged with emergency=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMGeological: Geological features from OpenStreetMap tagged with geological=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMHealthcare: Healthcare facilities and services from OpenStreetMap tagged with healthcare=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMHistoric: A historic site or monument from OpenStreetMap tagged with historic=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMIndoor: Indoor features from OpenStreetMap tagged with indoor=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMManMade: An artificial structure from OpenStreetMap tagged with man_made=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMMilitary: Military zones and buildings from OpenStreetMap tagged with military=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMOffice: An office or place of business from OpenStreetMap tagged with office=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMPlace: Geographical places from OpenStreetMap tagged with place=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMPower: Facilities for generation and distribution of electrical power from OpenStreetMap tagged with power=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMRoute: Established routes from OpenStreetMap tagged with route=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMTelecom: Telecommunication infrastructure from OpenStreetMap tagged with telecom=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMTrafficSign: Road and traffic signs from OpenStreetMap tagged with traffic_sign=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMWater: Bodies of water from OpenStreetMap tagged with water=* or natural=water. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

We are grateful to OpenStreetMap contributors from OpenStreetMap (This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.) for their contribution to these data models.

New data models OSMAdvertising and OSMBarrier at subject dataModel.OpenStreetMap

  By

We are pleased to announce the publication of OSMAdvertising and OSMBarrier within the subject dataModel.OpenStreetMap.

OSMAdvertising: Advertising installations from OpenStreetMap tagged with advertising=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

OSMBarrier: Barriers and physical obstructions from OpenStreetMap tagged with barrier=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

We are grateful to OpenStreetMap contributors None from OpenStreetMap (This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.) for their contribution to these data models.

Find all published Smart Data Models at smartdatamodels.org.

New data model OSMAeroway at subject dataModel.OpenStreetMap

  By

We are pleased to announce the publication of OSMAeroway within the subject dataModel.OpenStreetMap.

 

We are grateful to OpenStreetMap contributors from OpenStreetMap for their contribution to these data models. (This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.)

OSMAeroway: An aeroway feature from OpenStreetMap tagged with aeroway=*. This data model is a derivative work based on the OpenStreetMap Wiki, licensed under CC BY-SA 2.0 by OpenStreetMap contributors.

 

New data models mapping OpenStreetMap

  By

Fifteen new data models from the mapping of OpenStreetMap are now available in a new subject datamodel.OpenStreetMap

Thanks to the inspiration of Flavio Cirillo who currently works for NEC these models are now available, and thanks to the contributors of OpenStreetMap who created these models that are mapped here in this derivative work.

New data models will come shortly for this new subject

  • OSMAerialway. An aerial transport or lift from OpenStreetMap tagged with aerialway=*. Describes cable cars, gondolas, chair lifts, and drag lifts

  • OSMAmenity. A facility or amenity from OpenStreetMap tagged with amenity=*. Represents places of public or private use such as restaurants, schools, hospitals, banks, etc

  • OSMBuilding. A building or group of connected buildings from OpenStreetMap tagged with building=*. Represents the physical structure of a building, including its geometry, dimensions, materials, and functional classification. For specific functions within a building (shop, amenity, etc.) additional entities should be used.

  • OSMBuildingPart. A part or section of a building from OpenStreetMap tagged with building:part=*. Used to represent buildings with varying heights, roof shapes, or materials across different sections, enabling 3D building visualisation (Simple 3D Buildings standard).

  • OSMCycleRoute. A dedicated cycling infrastructure element from OpenStreetMap. Represents cycle paths, shared cycle lanes, and bike routes tagged with highway=cycleway or cycleway=* on road ways.

  • OSMHighway. A road or path element from OpenStreetMap tagged with the highway key. Represents all types of roads, from motorways to footpaths, as defined by the OSM highway taxonomy.

  • OSMLanduse. An area of land use from OpenStreetMap tagged with landuse=*. Describes the primary human purpose or use of an area of land

  • OSMLeisure. A place for leisure, sports, or recreation from OpenStreetMap tagged with leisure=*. Includes parks, sports pitches, swimming pools, stadiums, etc

  • OSMNatural. A natural feature from OpenStreetMap tagged with natural=*. Describes geographical features such as water bodies, woods, scrub, peaks, beaches, etc

  • OSMParkingArea. A vehicle parking area or facility from OpenStreetMap tagged with amenity=parking. Represents surface car parks, multi-storey garages, underground facilities, and other organised parking areas.

  • OSMPublicTransportStop. A public transport stop, station, platform or boarding point from OpenStreetMap. Represents nodes and areas where passengers board or alight from public transport services, tagged with public_transport=* or specific mode tags.

  • OSMRailway. A railway track or infrastructure element from OpenStreetMap tagged with the railway key. Covers all types of rail infrastructure, from mainline heavy rail to trams, subways and funiculars.

  • OSMShop. A shop or retail store from OpenStreetMap tagged with shop=*. Represents establishments selling retail products directly to end customers

  • OSMTourism. A tourist attraction or tourism-related facility from OpenStreetMap tagged with tourism=*. Includes hotels, museums, viewpoints, artworks, etc

  • OSMWaterway. A waterway from OpenStreetMap tagged with waterway=*. Describes rivers, streams, canals, drains, and other water courses

 

Use smartdatamodels in your local AI agent with this MCP server

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

With this MCP configuration file you will be capable to use Smart Data Models locally in your AI agent.

{
  "mcpServers": {
    "smartdatamodels": {
      "type": "http",
      "serverUrl": "https://opendatamodels.org/mcp/v1"
    }
  }
}
More information here
These functions are available
1. search_data_models
Search the Smart Data Models (SDM) catalog by keyword, domain name, or partial model name. Use this when the user wants to discover which data models exist for a topic (e.g., ‘parking’, ‘weather’, ‘energy meter’). Returns a list of matching model names and their subjects. Example: search_data_models({“query”: “air quality”, “domain”: “SmartEnvironment”})
2. get_data_model
Retrieve the complete JSON Schema and metadata for a specific Smart Data Model. Use this when the user already knows the model name and wants its full definition, required fields, attribute types, or documentation URL. Example: get_data_model({“model_name”: “WeatherObserved”, “include_examples”: true})
3. list_domains
List all available SDM domains (top-level industry categories) with the count of data models in each. Use this as the entry point when the user wants an overview of what sectors are covered, or before calling list_models_by_domain. No parameters required. Example: list_domains({})
4. list_models_by_domain
List all data model names available within a specific SDM domain. Use this when the user wants to browse all models in a sector such as SmartCities or SmartHealth. Call list_domains first to confirm valid domain names. Example: list_models_by_domain({“domain”: “SmartEnergy”})
5. validate_data
Validate a JSON payload against the schema of a specific Smart Data Model. Use this when the user has an IoT payload or NGSI-LD entity and wants to check if it conforms to the standard. Returns a structured result with pass/fail and a list of specific validation errors if any. Example: validate_data({“model_name”: “WeatherObserved”, “data”: {“id”: “urn:ngsi-ld:WeatherObserved:001”, “type”: “WeatherObserved”, “temperature”: {“type”: “Property”, “value”: 22.3}}})
6. get_related_models
Find Smart Data Models that are semantically related to a given model. Useful for discovering adjacent models when building multi-entity systems — e.g., related models for ‘OffStreetParking’ might surface ‘ParkingSpot’ and ‘ParkingGroup’. Example: get_related_models({“model_name”: “OffStreetParking”, “relationship_type”: “all”})
7. get_attributes_for_model
List all attributes (properties) of a specific Smart Data Model, including each attribute’s NGSI type (Property, GeoProperty, or Relationship), data type, description, recommended units, and reference model URL. Use this after get_data_model when the user wants to understand what fields a model has, what values they accept, or how to construct a valid NGSI-LD payload. Example: get_attributes_for_model({“model_name”: “WeatherObserved”})
8. get_attribute_details
Get full details for a single attribute within a Smart Data Model — including its description, NGSI type (Property/GeoProperty/Relationship), data type, recommended units, format constraints, and reference model URL. Use this when the user asks what type a specific field is, what units it uses, or how to populate it. Example: get_attribute_details({“model_name”: “WeatherObserved”, “attribute”: “temperature”})
9. find_subject_by_model_name
Find which SDM subject (repository group, always prefixed with ‘dataModel.’) a data model belongs to, given only the model name. Use this when you have an entity type from an incoming NGSI-LD payload but don’t know its subject — for example, if a payload contains ‘type: WeatherObserved’ and you need to resolve its subject before calling get_data_model or validate_data. Example: find_subject_by_model_name({“model_name”: “WeatherObserved”})
10. fuzzy_find_model
Search for a data model by approximate or misspelled name using fuzzy matching. Use this as the recovery step whenever get_data_model returns MODEL_NOT_FOUND — it finds the closest real model names even when the spelling is off. Returns ranked candidates with similarity scores. Example: fuzzy_find_model({“model_name”: “WeatherFora”, “threshold”: 80})
11. get_subject_repo_url
Return the GitHub repository URL for an SDM subject (e.g., ‘dataModel.Weather’). Use this when the user wants to browse the source files, open issues, or cite the authoritative schema location for a subject group. Example: get_subject_repo_url({“subject”: “dataModel.Weather”})
12. get_model_repo_url
Return the GitHub repository URL(s) for a specific data model by name. Use this when the user needs a direct link to the schema source, examples, or documentation on GitHub. Example: get_model_repo_url({“model_name”: “WeatherObserved”})
13. get_full_catalog
Return the complete list of all data models within a specific domain, including names, subjects, descriptions, and repository links. Use this when the user needs a comprehensive structured overview of an entire domain for bulk processing, analysis, or selection. A domain filter is mandatory to prevent returning the entire catalog in one call. Example: get_full_catalog({“domain”: “SmartEnvironment”})
14. export_model_attributes
Export the attributes of a data model as a flat delimited string, with caller-selected meta-fields per attribute. Use this when a data engineer needs a CSV-ready or pipe-delimited listing for database column mapping, ontology alignment, or spreadsheet import. Available meta-fields: property, type, dataModel, repoName, description, typeNGSI, modelTags, format, units, model. Example: export_model_attributes({“model_name”: “WeatherObserved”, “separator”: “,”, “fields”: [“property”, “type”, “typeNGSI”, “units”]})
15. get_model_context
Return the NGSI-LD @context URL and context content for a specific data model. This is required when building valid NGSI-LD linked-data payloads — without the correct @context, the payload is not valid linked data and will be rejected by NGSI-LD brokers. Use this before constructing or validating a normalized payload. Example: get_model_context({“model_name”: “WeatherObserved”})

New MCP service to use smart Data models in your local AI agent. Autonomous light management 4 Smart Data Models

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

Are you building AI applications for Smart Cities, Energy, or IoT? Interoperability is often the biggest hurdle—but a new tool is making it easier to keep your LLMs “in the loop” with global standards.

Introducing the Smart Data Models MCP Server, a new reference implementation that connects Large Language Models directly to the Smart Data Models ecosystem. Built on the Model Context Protocol (MCP), this server allows AI agents to browse, retrieve, and implement standardized data schemas in real-time.

Key Features:

  • Instant Schema Access: Give your LLM the ability to look up official data models for everything from street lighting to soil sensors.

  • Enhanced Accuracy: Reduce hallucinations by providing the AI with the exact JSON-LD and NGSI-LD structures required for your project.

  • Seamless Integration: Designed for easy setup with MCP-compatible clients (like Claude Desktop), enabling a smoother developer workflow for digital twin and IoT projects.

By providing LLMs with a “dictionary” of standardized data, the Smart Data Models MCP Server ensures that your AI-driven solutions are born interoperable.

Check it out on GitHub: agaldemas/smartdatamodels-mcp

In these slides are the detailed explanation of this  that can be reached here. See below the architecture and in the README the easy configuration.

Here there is the configuration file (there are several options)

{
  "mcpServers": {
    "smart-data-models-http": {
      "autoApprove": [],
      "disabled": false,
      "type": "streamableHttp",
      "timeout": 180,
      "url": "http://127.0.0.1:3210/mcp"
    }
  }
}

The source code is available here

Thanks to Alain Galdemas for the contribution