Thing in the future

Accueil > FAQ > Hands-on Thing’in : practical questions

Hands-on Thing’in : practical questions

Recommendations & best practices

A domain is used to delineate a given environment on a basis which may be both physical and legal, e.g. a building, a city. The domain name is used as a prefix of the identifier of the avatar (IRI). if you don’t find any domain in thing’in that could be usefull, you can define a new domain like this : http://Adomain/. In that case, the avatar of that domain will be addressed by the following IRI http://Adomain/myavatar1 For more details, see Thing’in wiki https://wiki.thinginthefuture.com/#Domain%20of%20an%20avatar

It’s highly recommended for an application to use Thing’in existing domains. Domains are shared between the applications.
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 . The first part part is the domain name used as a prefix (from the beginning to the last slash character) and the second part is the identifier of the avatar in the domain. Using the IRI , you can request an avatar or create a relation between two avatars.
For more details, see Thing’in wiki and $iri operator : https://wiki.thinginthefuture.com/#Avatars%20-%20Search

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 https://wiki.thinginthefuture.com/#Access%20Control