[Fiware-ngsi] About attribute domain and its metadata

[t.elsaleh at surrey.ac.uk]

Many thanks Laurent for the UML.

Could anyone point out if there is some reference/documentation about the NGSI data/operation structure (not the "binding" document)?

Also, could someone briefly explain what the svn NGSI-9 example "registerContextRequest.xml" is trying to do? There seems to be 2 entities; "conference room" and "office room". How are the attributes in "the contextRegistrationAttributeList" element related to the entities defined above?

Best regards,
Tarek



From: laurent.artusio at orange.com [mailto:laurent.artusio at orange.com]
Sent: 26 September 2012 08:00
To: Elsaleh T Mr (Electronic Eng)
Cc: DUPONT Laurence RD-BIZZ
Subject: RE: [Fiware-ngsi] About attribute domain and its metadata

Here is a data model for NGSI 9-10. It is not official nor perfect. We did it for our own understanding, feel free to use it. You should correlate it with the NGSI XSD, because it lacks some data structures like the ones used as parameters in NGSI methods ( for example "QueryContextRequest")

Best regards,

Laurent

De : 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]<mailto:[mailto:fiware-ngsi-bounces at lists.fi-ware.eu]> De la part de t.elsaleh at surrey.ac.uk<mailto:t.elsaleh at surrey.ac.uk>
Envoyé : mardi 25 septembre 2012 15:54
À : fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Objet : Re: [Fiware-ngsi] About attribute domain and its metadata

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> [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<mailto: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

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120926/cc679f41/attachment.html>