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>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy