the ucode. A distinction is made between physical ucode which are by definition
stored in a Tag attached to the entity, and logical ucode which are not stored in
any Tag and are mainly used for identifying intangible objects as described
above (including relationships between ucodes).
The main idea behind allocating ucode to relationships between entities comes
from the Resource Description Format used to model knowledge. RDF
knowledge is made of triple <subject, relation, object> where each constituent
of the triple is made of a URI. In the case of ucode relationship each ucR unit is
a triple of ucodes. Information associated with the two entities and the relation
can therefore be found querying the ucode resolution server.
In addition resulting from this establishment of relations between entities, are
graphs (ucR graph) where single ―subject‖ ucode gets linked to many ―object‖
ucode via various ―relations‖. Objects which are not ucodes are called ―atoms‖.
A subject ucode pointing via a relation towards a URL is a typical example of
such rules involving atoms.
uCode Resolution Server
The resolution of ucode is achieved in the ucode Resolution Server The
simplified resolution consists of taking the ucode read by the reader, searching
for ucR units that correspond to that ucode and returning to the mobile terminal
the addresses of content associated with the ucode via the relational database
introduced earlier (similar to a triple store).
The Ubiquitous ID architecture can be simply described as follows (Figure 107 ):
Objects
Places
Ucode
Ucode
User Terminal
Ucode
ReSseorvluetironApplication
InSfoerrmvcatieionFigure 107 : Ubiquitous ID architectureFrom the descriptions of the various entities of the architecture (see Figure 107 )
above, the following table of concepts could be derived:
uID Concept IoT Reference Model
ConceptCommentsTangible Object Physical Entity
Intangible Object Digital Artefact If the intangible object is a representation
of a tangible object, then it is also a Virtual
Entity