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.