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.
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.
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>
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
> www.linkedin.com/in/jhierro
> Twitter: @fiware <https://twitter.com/fiware> @JuanjoHierro
> <https://twitter.com/JuanjoHierro>
>
>
>
>
>
>
>
>
>
>
> __________________________________________________________________________________________
>
> 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
>
> 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/0b561c74/attachment-0001.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/0b561c74/attachment-0001.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy