[Fiware-ngsi] About attribute domain and its metadata

[t.elsaleh at surrey.ac.uk]

Hello All,

Is there a UML for NGSI-9/10? Because I also seem to be confused.

In my case, wrt the relation between different elements in a description, e.g. "context registration". From the example given in the SVN ("registerContextRequest.xml"), the attributes are separated from the entities. Whereas I would have thought that they would be child elements for each entity element.

So, how are the attributes/metadata "attributed" to the respective Entities?


Best regards,
Tarek




From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Ken Zangelin
Sent: 25 September 2012 14:01
To: Martin Bauer
Cc: fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] About attribute domain and its metadata

Ok Martin, thank you very much for the information.
I clearly still have a lot to learn ...

BR,

/KZ


On 09/25/2012 02:41 PM, Martin Bauer wrote:
Hi Ken,

An attribute domain is a logical concept for grouping context attributes, so that you can update, query and subscribe for the whole group. Reading your e-mail, it seems that your view is very much centered around the way you implement this, but these implementation aspects are not covered by NGSI. It is important to understand the concept. Attribute domains are not "created" once - they exist and there may be different registrations pertaining to the same attribute domain.

The IsDomain part of the ContextRegistrationAttribute just indicates whether the content refers to a single ContextAttribute or the AttributeDomain. If you send a register with a ContextRegistration that contains a ContextRegistrationAttribute and IsDomain=true then you are actually looking at an AttributeDomain and the Metadata refers to the AttributeDomain. It means that you can ask the ProvidingApplication for this AttributeDomain. Different ProvidingApplicaitons may register for the same AttributeDomain, i.e.,  on request you need to return all ProvidingApplications for an AttributeDomain to the ContextBroker and it will ask the respective ProvidingApplications for the information and merge the results before returning them to the requester.

ProvidingApplications may update the registration with a new registration within the originally provided registration time. ProvidingApplications may also provide a new registration if the Metadata has changed, so there can be updates to the Metadata.

The updateContext request is an NGSI-10 operation and should not be relevant for the ConfigurationManagement implementation.

Best regards,

Martin

------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu<http://www.nw.neclab.eu/>

*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014

From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Ken Zangelin
Sent: Tuesday, September 25, 2012 9:56 AM
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: [Fiware-ngsi] About attribute domain and its metadata

Hi all ngsi lovers :-)

The ngsi specs aren't that clear about attribute domains and I would like to share my understanding of it.
It's important we all understand this the same way ...


Attribute Domain Name and Domain Metadata

Each entity has one unique Attribute Domain (one or none).
The attribute domain can be 'created' using the registerContext request or using the updateContext request.
Once created, it cannot be 're-created' - its name will stay as is.

The first entering attribute with 'isDomain=yes' is used to create the attribute domain (of its entity).
The name of this 'special attribute' will be used as the attribute domain name for the entity
and its metadata will be set as domain-metadata for the entity.
So, no attribute is created, just the domain itself.

When subsequent 'isDomain == true' attributes enter (using registerContext or updateContext),
no new domain is created - only that this attribute is part of the domain that already exists.
The metadata of this attribute is treated as private metadata of the attribute and not as
domain metadata.

If any metadata coincides with a domain metadata (in name and type), it will not be added as
private attribute metadata, but the domain metadata will be updated. This is true for all attributes,
not only the ones with 'isDomain == true' - as the domain metadata is common to all attributes.

Now, how do we add domain metadatas to an entity?
One way would be registering another 'isDomain=yes' attribute with the very same name as the attribute domain,
and add the metadata of this 'attribute' as domain metadata.
Either that, or we invent a special attribute name, like 'domainMetadataAddition' for addition of metadatas.
I see no other way of adding domain metadata.


So, comments are more than welcome ...

BR,

/KZ
________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120925/bf580de7/attachment.html>