An Access Control (AC) is a set of permissions or rights associated with a resource. An AC specifies which users are granted access to which resources, as well as what operations are allowed on given objects. Thing in associated ACs to resources such as avatars, and various API to interact with the platform. AC can also be applied to user role so that all the users of a certain role share the same permissions.
An access key is a token (JWT) provided by the user on each request it executes on the API in order to authenticate him self. This Token embeds information about his identity (internal id in Thing in), the role he plays (then, in fine, the actions he can do), the expiration time (an AK has a short life duration, generally one hour). A user obtains an AK after his authentication.
Access modalities are data structures attached to avatars that decribe the capabilities of the concrete object behind the avatar and how to interact with this object.
An APi is a computer interface that defines the type of request that can be made on a system, how to make them, as well as the data format for requests and responses.
The Thing in platform provides a set of web APIs for developers to interact with the graph of avatars and the ontologies.
Describes geoloc primitives and to attribute (data properties) historizations
The Thing'in platform stores avatars which are digital representations of physical things. An avatar can represent a connected device (as customarily used in the IoT), a non-connected thing, or a system made up of such things in the environments such as trees, streets, etc…. Thing'in is built upon a graph database, where avatars are the nodes of the graph.
Avatar IRIs are IRIs (Internationalized URIs, as defined by RFC 3987) used to uniquely identify an avatar in an "open world" interoperable way.
An ACL is a data structure attached to an avatar defining what actions are allowed to which users. An ACL can control the visibility of an entire avatar as well as controlling the visibility at the attributes levels. At the creation, an avatar is only visible to its owner who can further extends its visibility to other users.
In Thing in, we take the choice to implement Attribute-based access control (ABAC) to give fine control allowing to define access control at the data property level in regards of Avatar / User / Request / Context attributes. So, for instance one can define an ACL on their avatars to forbid the access to the geolocation data property and any modifications on the relationships.
Recall that only digital representation of things, avatars are stored in the platform. In order to access to data that may be produce by the concrete things behind the avatars, an access modality is required. Access modality of an avatar is a data structure with the all the necessary information required to access and interact with the things behind the avatar. For instance, an access modality could describe an API to access to the stream of a camera.
A domain is a container of graphs, and avatars therein. An avatar should belong to a single domain. To ease the identification of the avatar (IRI), the IRI is built with the domain name and a uuid string.
domain name = http://www.orange-labs.com/thingin avatar IRI = http://www.orange-labs.com/thingin#livebox102458
The consequences of this definition are:
The properties (or attributes) of an avatar, captures by a key-value pair They //may// be described by reference to OWL data-properties defined in semantic web ontologies. The target values of thee properties may used data types such as those defined by JSON . The "key" part of a preoperty //may //be defined by reference to an OWL data property which defines the semantics of this property as well as constraints on how to use this data property. For instance a data-property can define the value type of a property (e.g. integer, string, etc.) as well as the semantic classes on which the property could set. If such a reference is used, the data properties used to define attributes of an avatar should be compliant with the semantic classes of the avatar.
Relationships between avatars stand for actual physical or physically-grounded connections or causation effects between the things that these aatars stand for. Relationships are first class citizens of the property graph data model, and may have properties of their own, just as avatars. They are captured by arcs (directed edges) of the Thing'in graph, as stored in the database.
They have a type, just as an avatar, which //may// be defined by direct or indirect reference to an OWL "object property", but
The type of an avatar references a generic or semi-generic category to which instances of this avatar belong, and may provide a flexible template with predefined property "slots". This type //may// reference, directly or indirectly, classes defined by OWL ontologies, concepts from SKOS thesaurii, or terms borrowed from a taxonomy or controlled vocaulary (such, e.g. schema.org).
A blob is a file containing non-structured or weakly structured data such as pictures, manuals, plan, map, etc. that can be registered in the platform and attached to an avatar. A blob storage service is implemented by Thing'in to allow users to store blobs and link them to avatars.
A Thing'in enabler is a specialized software building block developed using the Thing in APIs which provides special features to the platform. Enablers can also provides APIs for third party developers. An example of such enablers is the Thing'in 3D graph visualisation tools
Database where data is structured as nodes and relations. Nodes are linked by relations, which are exclusively binary, contrary to those used in relational databases. Examples of well-known graph databases are Neo4j, ArangoDB, OrientDB.
A hypernode stands for a subgraph of the Thing'in graph, which groups together a cluster of avatars composing a system . e.g. a hypernode could capture the security system of a building, composed of all the devices, controllers, etc. and connections that make up this security system //together with the relationships describing how they are assembled into this system //. The clusters give a new level of management of avatars. An avatar belong to several clusters represented by hypernodes and these clusters could be nested. Specific ACL rights could be given to users that are identified as manager of the cluster over the avatars that it contains.
An Identity provider references the users, the information about their identity. In general, it's up to the service, in front of the users, to define the IDP it wants to use.
Thing in can be seen as an enabler to build services, then it not here to impose an IDP. Then when using Thing in, the service can continue to use his prefered IDP (like Orange, LiveObject, Google) but Thing in should trust this one to authenticate the users who are referenced in.
Nevertheless, Thing in provides next to the external Identity Providers a dedicated IDP (deployed in the platform) that aims to reference users for the tests, development, or adminstration of the platform.
The process of producing new information (e.g. an extension of the graph) from existing information (e.g. the current graph).
Json web token, defined by RFC 7519, is used in Thing in API to authenticate the user and to give information about his identity and his role. This token is secured (signed) by the private key of the platform, and anyone can validate it with the public key of the platform (embed in the certificate).
A JWT must be passed at http authorization header for each call to Thing in API. To obtain a JWT, a user should ask it through the authentication endpoint. A JWT has an expiration date and then the user should renew it when needed.
Standardization of the property graph information model, specified by ETSI, used by Thing'in as its formal information model. NGSI-LD provides an RDF-based formal definition of the property graph information model, specifies how a Property Graph can be serialized as an RDF graph, and how the nodes of a property Graph (NGSI-LD entities) can reference ontological classes through NGSI-LD types.
When a trigger is triggered, a notification is sent so the notification is just the piece of information you receive and which describes the changes that have occured on the avatard graph database.
An ontology is a formal representation (knowledge) of a domain using a set of concepts of the domain and how these concepts are related. Thing'in leverages semantic web ontologies described using theThe W3C Web Ontology Language (OWL) which is a Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things.
Generic information model used by most graph databases, wherein nodes (vertices of the graph) and relations (directed edges/arcs of the graph) can have attributes (properties), under the form of key-value pairs
A graph formed by a collection of RDF triples where nodes are resources or literals and relations are predicates.
The process of reaching a goal or solving a problem (e.g. select the best ressource, best with respect to a set of evaluation criteria) by using information reflecting a well defined situation (e.g. the content of the current graph). One potential approach is by organising and chaining a set of inferences.
A family of W3C specifications for modeling knowledge. The basic unit of information is an RDF triple which consists of a subject, a predicate, and an object. A subject represents a resource which can be a thing or a concept, identified with a unique name of identifier. An object can be a Resource or a Literal i.e. a value such as string, number, dates, etc. A predicate defines semantically the relation between the subject and the object.
A Security group is composed of a set of avatars protected by an ACL and a set of users that can access to those avatars. An avatar could belong to one and only one security group but a user could belong to several security groups. Security groups could be used in ACL conditions to validate the access to an avatar by a user (e.g. access is authorized if the avatar security group is in the list of the user security groups)
Possibility for third party partners to deploy and operate instance of The Thing in platform on their own infrastructure. An instance of Thing in (TiPod), it always registered to a central entity (federator), to prove this registration it get a thing in certificate. Any one connecting to a TiPod can verify if this TiPod is certified. The set of certified TiPods shape a Thing in trusted network. All the users of this network can view shared avatars of all the TiPods.
A Thing in pod is an instance of a Thing in platform that is operated by a third-party partner. A TiPod can take part to the Thing in federation system.
A federation server is set in place to certify the TiPod that take part to the Thing in federation system, identify avatar domains of each instance in order to optimize federated queries overs several TiPods. The federator maintains a life line to all the refereced TiPods, allowing a better scheduling of the request cross TiPod.
A trigger describes part of the avatar graph we want to be notified when some change occurs.
Different kinds of users are defined in the Thing'in platform from guest user with very limited permissions to admin users with the largest permissions set on the platform. Almost all requests on the avatar API required a JWT token from an authenticated user, except for guest type of users. Ontology APIs are also public and do not require to be authenticated.
Thing in uses a Role Base Access Control (RBAC) mechanism to define the level of permission a user can have.
Role Based Access Control (RBAC) are used to define the permission of users on various resources such as in the platform. By default several roles are defined : user, provider, service provider, supervisor, admin.