Dear Juanjo, all,
I would also introduce another point in the discussion… looking at the AASX file specification we have identified another decision to be taken in the mapping toward the NGSI/NGSI-LD.
[cid:6C2835EC-51F6-4699-837C-714E36A8FFD3 at lan]
Considering the attached screenshot (taken from one of the few AASX example available online), we should also define the approach to handle nested entities (I mean the entities under the first level). Should we map each sub-level to a new entity? If yes, how?
In any case, we should also have specific capabilities in the API of the NGSI-LD broker (the current implementations seem not exposing such behaviour, but we should investigate it further): we would be able to insert/update large entities (1-1 mapped with a ASSX file) and all the nested entities within using just one query, or we may prefer a lazy approach (especially for querying), or even better we can specify the approach as part of the query parameters.
My 0,02€
On 25 Nov 2019, at 14:57, Juanjo Hierro <juanjose.hierro at fiware.org<mailto:juanjose.hierro at fiware.org>> wrote:
On 25/11/2019 12:45, Ken Gunnar Zangelin wrote:
Hi all,
attribute domains ... no, we did never use that in APIv1 and because of that, we didn't introduce it in APIv2 nor NGSi-LD.
I must confess I don't even remember what it was all about.
I will have to study it a bit, from the old OMA NGSI 9/10 docs.
There is not that much described in the specifications. However, I believe that the concept is very much close to the concept of submodels supported in the description of AASs.
My understanding is that "attribute domains" (let's call them "property domains" from now on) are a way to identify a number of properties of an entity. IMHO, this would be a helpful concept in many applications. It would allow me to query for a set of properties of an entity related to a topic (e.g., give me all properties of the entity related to "Energy efficiency") without knowing how many properties they will be. This will be helpful in applications where the set of properties linked to "Energy efficiency" vary over time because the model gets expanded.
However, to give a quick answer - if an attribute domain is simply a grouping thing (don't want to use the word "entity" :)) that attributes can belong to,
we could reserve a metadata name for this purpose ("domain" for example). Well, in NGSi-LD a metadata would be a Property-of-Property.
What we don't want to do is to change the orion data model - that's why we'd need a reserved metadata name.
When trying to find a mapping for the concept of submodels supported in AAS, Francisco and me came with the same idea of mapping the notion of submodel into a standard property (e.g., "submodel" or "AAS submodel" which has as value the id of the submodel. However, I'm afraid that some operations would be a bit tricky to support:
* Update all the properties of a given property domain in one shot (this is not particularly a bit deal, I guess but)
* Subscribe to changes on any of the properties of a property domain in one shot
* register a context provider for any of the properties of a property domain in one shot
All these operations sound valuable to me and I'm afraid would be a bit tricky to implement if we stick on properties of properties.
I believe it is worth extending the current model of NGSI-LD with a functionality which a) doesn't change anything that was there before since it is just added functionality, b) is enough powerful itself, probably bringing a new distinguishing feature compared to other "competing services" and c) allows us to support a direct mapping between AAS concepts and NGSI-LD, which would be of strategic value.
Cheers,
Juanjo
Now, for queries ...
While the query type "?q=attr.domain==kitchen" already is implemented, there's nothing like "q=*.domain==kitchen", which is what we would need for this.
Same same for subscriptions.
To implement that in the query language itself would be very easy, but we'd need support from it in the database as well.
We would need for mongo to offer that kind of service and I'm not sure mongo offers anything like it. Perhaps with some obscure REGEX, but for the LHS (Left-Hand-Side), not the RHS ...
In the worst case, retrieve ALL attributes and filter them later (on the domain name). That is of course not very good from a performance point of view.
[ We *are* able to retrieve entities based on existence of attributes ... this is a little bit like that, just one layer further down ]
To really answer this question, I'd need some time to look into this. Matter of priorities.
I will discuss this with Juanjo asap.
I'll end with a question.
Would we want attributes to be able to belong to more than one domain at the same time?
Best regards,
/KZ
On Mon, Nov 25, 2019 at 12:11 PM Juanjo Hierro <juanjose.hierro at fiware.org<mailto:juanjose.hierro at fiware.org>> wrote:
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,
--
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>
<foundation-logo.png>
__________________________________________________________________________________________
You can get more information about our cookies and privacy policies on the following links:
- https://wiki.fiware.org/FIWARE_Privacy_Policy
- https://wiki.fiware.org/Cookies_Policy_FIWARE
Fiware-roadmap-digital-twin mailing list
Fiware-roadmap-digital-twin at lists.fiware.org<mailto:Fiware-roadmap-digital-twin at lists.fiware.org>
To unsubscribe from Fiware-roadmap-digital-twin mailing list, go to the information page of the list at:
https://lists.fiware.org/listinfo/fiware-roadmap-digital-twin
__________________________________________________________________________________________
You can get more information about our cookies and privacy policies on the following links:
- https://wiki.fiware.org/FIWARE_Privacy_Policy
- https://wiki.fiware.org/Cookies_Policy_FIWARE
Fiware-roadmap-digital-twin mailing list
Fiware-roadmap-digital-twin at lists.fiware.org<mailto:Fiware-roadmap-digital-twin at lists.fiware.org>
To unsubscribe from Fiware-roadmap-digital-twin mailing list, go to the information page of the list at:
https://lists.fiware.org/listinfo/fiware-roadmap-digital-twin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-roadmap-digital-twin/attachments/20191125/859c5e23/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 30990 bytes
Desc: image002.jpg
URL: <https://lists.fiware.org/private/fiware-roadmap-digital-twin/attachments/20191125/859c5e23/attachment-0001.jpg>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy