Hands-on Thing’in : practical questions
Recommendations & best practices
A domain is used to circumscribe a given environment on a basis which is mostly physical, but may be also legal, or administrative : e.g. a building, a city, a department. The domain name appears as prefix of the identifiers (IRIs) of avatars that belong to this domain. These avatars may belong to only one domain. If you don’t find any existing domain in Thing’in that matches your needs, you may define a relevant new domain (http://example-domain/) and all avatars belonging to that domain will be addressed by IRIs such as http://example-domain/myavatar1. For more details, see Thing’in wiki
It’s highly recommended for an application to use existing Thing’in domains, and that these domains be defined on the basis of permanent features of the environment, rather than on the transient requirements of each application. Domains are meant to shared between all applications in a given environment.
Creating several domains used by your application could also be an option if you want to provide a limited view to some users. Domains allow you to limit the view of a set of avatar to certain users.
For exemple : domain_A is http://domain_X/subsetA/
Domain_B is http://domain_X/subsetB/
A user that is granted rights on domain_A can’t access nor see the avatars that are managed in domain_B.
A user that is granted rights on domain_B can’t access nor see the avatars that are managed in domain_A.
A user that is granted rights on http://domain_X/ can access all the avatars that are managed in the application domain (subsetA + subsetB).
An IRI identifies an avatar in Thing’in. An IRI can be split into 2 parts
For more details, see Thing’in wiki and $iri operator
The recommendation is to create at least two different accounts. One account with read only access to the avatars of one or more domains. A second account with more rights ( ie : read write access on all the avatars). Access management is based on Role Based Access Control. Each user is assigned a set of roles that will allow him to perform some actions. A role is a collection of permissions that can be applied to users. A standard user has a user role. Provider role permit a user to create new avatars in Thing’in. Service-admin role has been designed for application manager in order to manage a service and its users.
For more details, see Thing’in wiki
The ontology lookup service provided by Thing’in is the first place where to look for.
Search ontologies by tags : use the Explore menu > Explore Ontology Lookup Service and get ontologies by tags
Search classes : use the Explore menu > Explore Ontology Lookup Service and search classes (utilise Elastic search ou lucky finder)
Filter on the title or the prefix or tags ; use the Explore menu > Explore Ontology Lookup Service and get the full list of ontologies. Then filter the list.
The NGSI-LD cross-domain ontology is the default reference ontology that should be used for generic relationships such as “hasPart”, or “isContainedin”, generic entity classes such as mobile/movable/stationary, and generic properties such as “createdAt”.
If I don’t find suitable types in existing ontologies, for new elements (entities, properties or relationships) that I need to characterize, should I define my own personal ontology to contain new ad hoc types of mine, customized to serve as perfect-fit templates for my needs ?
The answer is, in principle, NO : 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.
Log in Thing’in and use the technical portal.
- use the Explore menu > Explore Ontology Lookup Service and get the full list of ontologies. You can filter the ontology list by their title, prefix, tag.
- use the Develop menu > OLS API reference
Follow the instructions and documentation of all the endpoints to test it
Example of queries to get the ontologies list : https://olsapi.di.thinginthefuture.com/api/v2/ontologies
To be able to add tags on tthe ontologies, the developer role is required.
Once you’re logged in Thing’in portal, select the Provide menu > Ontologies. Use the endpoint PUT /ontologies/id : follow the instructions at this endpoint to add the tags.
Log in Thing’in and use the technical portal.
- Use the Provide menu > Ontologies > Submit a new ontology : Upload a new version of the ontology. Uploading its imports is optional if they already exist in the system. This action requires the provider role.
-Use the Develop menu > OLS API reference to go through the OLS API. Use the endpoint PUT /ontologies : follow the instructions at this endpoint to test it.