[Fiware-roadmap-digital-twin] Rescuing properties domains for enabling usage of NGSI-LD to access information of AASs

Juanjo Hierro juanjose.hierro at fiware.org
Mon Nov 25 12:11:43 CET 2019


Hi all,

   As you know, one of the tasks we are involved in has to do with 
definition of a mapping that allows to use NGSI-LD for the management of 
the information describing an Asset Administrative Shell (AAS).  This 
mail is a first mail addressing topics that are relevant to come with a 
complete and elegant mapping.

   The specifications about Details of the Asset Administrative Shell 
<https://drive.google.com/file/d/1CA4BczEin0f3hMFAV8uNayHRz7880ljS/view?usp=sharing> 
recently produced by the Industrie 4.0 group defined an metamodel built 
around a number of concepts for which such mapping has to be defined.  
While the mapping of some concepts is straightforward, the mapping of 
other concepts is more tricky.   Thus, AASs can be mapped easily to 
Entities and Properties to Properties.  However, we need to define what 
can be the mapping for "Submodels" and "Views".

   These two concepts can be considered just as a way to group 
properties of an AAS which is meaningful for different purposes. 
Submodels allows to group properties of an AAS based on aspects. Thus, 
we may group the properties that are relevant for thee management of 
"Energy efficiency" of a Drilling Machine and the properties that are 
relevant for the management of "Drilling functions" of that same 
Drilling machine.  We understand that one potential advantage for this 
would be the ability to perform updates or queries on submodels in 
single shots.   On the other hand, It should be possible to filter 
elements of the Administration Shell or submodels according to different 
"views".

   Interestingly, the concept of submodels had somehow a direct mapping 
to the concept of "attribute domains" in the OMA NGSI-9/NGSI-10 
specifications 
<http://www.openmobilealliance.org/release/NGSI/V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf> 
(see section 5.2.2)  Attribute domains were defined as "the grouping of 
multiple attributes. Attribute domains allow requestors to specify a set 
of attributes of interest using a single string as attribute domain 
name." (where we say "attribute" we of course refer to "property"). 
However, this concept of "attribute domain" was dismissed both in FIWARE 
NGSIv2 specifications as well as in ETSI NGSI-LD specifications.

   The reason of this mail is to gather information why the attribute 
domain concept was finally dismissed and whether it would be worth 
rescuing this concept for the sake of a more direct mapping of AAS 
concepts into NGSI-LD.   Personally, I always thought that keeping that 
concept had been useful because, among other things, would allow to 
retrieve a set of properties/attributes of an entity (those that define 
the domain) in a single shot, subscribe to changes on those entities, etc.

   @All: what is your opinon?   Should we rescue the concept in NGSI-LD 
given the fact a) it could be useful in certain scenarios, b) would ease 
the definition of a direct mapping of the concept of submodel in the AAS 
metamodel?  My response would be positive.

   @Ken: how difficult it would be to implement this concept of 
"property domain" ?  It would mean to support the idea that a number of 
properties could be logically grouped using a property domain identifier 
within the scope of a given entity and then allow to use that identifier 
to query for the value of all the properties associated to a given 
property domain, to be able to update all of the properties associated 
to a given property domain in a single operation, be able to subscribe 
to changes on any of the properties of a given property domain, ... 
things like that.

   Looking forward your response.

   Cheers,

-- 
Document
Juanjo Hierro
Chief Technology Officer
juanjose.hierro at fiware.org <mailto:juanjose.hierro at fiware.org>
www.linkedin.com/in/jhierro <https://www.linkedin.com/in/jhierro>
Twitter: @fiware <https://twitter.com/fiware> @JuanjoHierro 
<https://twitter.com/JuanjoHierro>









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-roadmap-digital-twin/attachments/20191125/32e25fcb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foundation-logo.png
Type: image/png
Size: 8201 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-roadmap-digital-twin/attachments/20191125/32e25fcb/attachment.png>


More information about the Fiware-roadmap-digital-twin mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy