|
The contents of a "data" section of a façade is the result of a kind of bookkeeping, with data flowing in (populate method) and flowing out (handover method), with a few sets of data that entered the "data' section in another way. These are:
In the example below only the first two of these extra types of data are shown. We will populate the "me03" system facade successively with two transfer files. In the first file vessel V-6060 has a nominal volume capacity of 50 m3, and that is changed into 60 m3 in the second transfer file. |
The contents of the "data" section of Facade #1 after the execution of the populate API method with the data of the first transfer file is as shown below:
After the second time of executing the populate API method the situation in the "data" section of Façade #1 is as follows:
The bottom four quads represent an instance of a template that "ends" the temporal part http://www.pqr-ltd.com/4502/me03#FPO-ves347621-20080116T102537Z
that was the 'possessor' of the nominal volume capacity of 50m3 that no longer is valid.
The new temporal part #FPO-ves347621-20080120T100500Z is now valid and possesses a nominal volume capacity of 60m3.
By executing the handover API method we move the information that:
from this Façade #1 (the "me03" system façade) to Façade #2 (the "ves" group façade).
After successful hand-over the "data" section of Façade #1 looks like:
|
Note that:
Whenever some template somewhere in the CPF (Confederation of Participating Façades) refers a handed over thing, for example to: http://www.pqr-ltd.com/4502/me03#ST-ves267723 being the rdf:object of the 'hasAsInfo' property of an instance of oim:ST-DOCUMENT_CELL-0096-001, and it would be queried as such, the above sameAS can be used to redirect that query to http://www.pqr-ltd.com/4502/ves#ST-ves267723 .
|
If we now add the "preload data" (in the bottom 86 quads) the overall picture becomes: