Thing in the future

Home > FAQ > Information Model

Information Model

Thing’in can store:

  • Information about instances of physical devices, things, systems, as NGSI-LD entities, corresponding to Thing’in avatars
  • All kinds of physical connections between them, represented as NGSI-LD relationships
  • Properties of both these entities and relationships, represented as NGSI-LD properties (key-value pairs)
  • References to “well-known” (i.e. shared) semantic categories/classes or types, drawn from ontologies , which characterize these individual instances of entities, relationships and properties
  • The referent entity that a Thing’in avatar (a Thing’in graph node) stands for is supposed to exist somehow in the real world, independently of the Thing’in platform that maintains its representation. Though the NGSI-LD specification does not apply this restriction, Thing’in nodes are supposed to stand for something strictly physical, with persons excluded for legal and privacy reasons. Thing’in nodes cannot represent a purely informational construct such as a legal entity, a role, a movie, an event, etc.
  • NGSI-LD nodes from the “graph” class are different from regular nodes in that they identify clusters of other NGSI-LD nodes that make up a subgraph, and they stand for a system with one level of indirection, i.e. through the nodes they group and the relationships that connect them. These systems cover all the spectrum between the following :
    • loose federations of things, coupled as systems by belonging to the same NGSI-LD subgraph : e. g. a supply-chain networks, vehicle sharing systems, short-term rental system
    • physically distributed systems and physical networks : e.g. telecom networks at the infrastructure level, water or electricity distribution networks, surveillance systems, etc.
    • federation of independent entities operated by the same stakeholder, at any scale, like e.g. , a like a desktop computer and various peripherals, a logistical network, a waste collection network, or, in different vein, a sharing system grouping physical assets
    • systems of systems in the sense of the customary definition a bottom-up assemblage of subsystems which are operationally independent and have not have been designed to work together, but which do happen to work together to provide a functionality that is more than the sum of those provided by the individual subsystems separately; examples are the Internet at large, or a city, be it smart or not!
  • NGSI-LD is a standard for Context Information Management defined by the ETSI CIM Industry Specification Group. It comprises an API and an information model, upon which the API rests, though the current version of the API does not explicitly make use of all constructs and capabilities defined by the information model.
  • The use of NGSI-LD as a standard for Context Information is recommended by, among others, the European Commission through the “” Smart Cities initiative, in a declaration signed (so far) by 68 cities throughout the EU
  • NGSI-LD provides a formal and de jure standard definition for the Property Graph information model, which has emerged as the de facto common denominator of all existing graph databases. Such a standard did not exist before NGSI-LD came about
  • NGSI-LD does extend in a few regards (such as allowing relationships of relationships and properties of properties) the customary use of Property Graphs used by graph databases
  • NGSI-LD does not directly account for the notion of “label” (as distinct from a property) used by a few graph databases such as Neo4J.
  • the NGSI-LD meta-model and cross-domain ontologies are formally defined on the basis of RDF/RDFS/OWL, as full-fledged OWL ontologies with axioms and restrictions
  • JSON-LD, as a serialization format for RDF, is used by the NGSI-LD API. All information captured in a NGSI-LD graph such as Thing’in can be serialized with JSON-LD using blank-node reification?
  • RDF graphs represent but a minuscule subset of a huge repertoire of long-established modeling usages of graphs, which have been developing over 300 years. RDF graphs should be seen as a lowest common denominator information model. They encode indistinctly, as logical predicates, every bit of data/information about a physical system, whereas Thing’in aims at representing digital twins of these physical systems as a whole, directly through a graph model that matches their structure.
  • RDF graphs are inherently less expressive than property graphs (PG). The difference is not one of degree, but of kind, PGs corresponding to second-order logic while RDF is limited to first order logic. The conversion of property graphs to RDF requires the use of reification , which, to express statements about statements, entails an (up to fourfold) expansion in the number of statements and obfuscates the underlying structural semantics of the property graph
  • RDF graphs are inherently less efficient than property graphs as an information storage vehicle, because they code entity attributes as properties, thus in the same way as actual graph arcs, even though they are dead-ends and meaningless arcs from a graph-modeling viewpoint
  • properties are seen as “internal” to the entities or relationships they qualify, just as attributes in object-oriented modelling
  • this avoids cluttering the graph with dead-end arcs : arcs that stand for physical relationships have, by contrast, a structural counterpart and a semantics of their own that comes from matching this structure

Thing’in does not yet support relationships of relationships, which are part of the NGSI-LD information model specification.

YES, as per recommended linked data practices, they are identified by IRIs that may be used to reference them externally, matching their internal identifier from the database

An NGSI-LD graph is normally at finer granularity and will generally single out a subgraph of a reference graph corresponding to a given domain : in a building domain, an NGSI-LD graph may capture e.g. the security system or the HVAC system. In some cases, an NGSI-LD graph may, however, correspond to a very large-scale distributed system that has components (nodes) across several domains (like the electrical grid in a city, which terminates into buildings that may me defined in their own domain.

An ontology if the formal definition, within a given universe of discourse, using an ontology language such as OWL, of a consistent set of concepts/classes, together with the axioms, constraints an relationships that bind them together and with referent individuals. An ontology may also associate properties to these classes

If you don’t find suitable types in existing ontologies, for new elements (entities, properties or relationships) that you need to characterize it is not recommended to create your own personal ontology to contain new ad hoc types of yours, customized to serve as perfect-fit templates for your needs.
Ontological types are meant to be shared. Defining customized or ad hoc types to be used in one single environment or application defeats their very purpose. If existing types defined in shared public ontologies are not specific enough, it is better to use multiple typing to characterize more closely a new-found entity. Supposing we wish to define a light bulb as being a “smart” radio-network-actionable light bulb, it makes much more sense to define it as inheriting both the traditional lighting appliance category (which defines it as providing a lighting service, just like, a candle), and the connected device, or networked actuator categories.

YES, multiple typing does always make it possible to complement and restrict later on a first default type which would be too broad, or weakly defined ; beware, however, that taxonomies have no built-in safeguards against inconsistencies in the use of classes.