[Fiware-data] Peer review of Data/Context Management Backlogentries

[Jose Maria Fuentes Lopez]

Dear all,

 

Here you have some more feedback regarding backlog entries.

 

Talk to you on Tuesday.

 

Best regards,

 

Chema Fuentes.

 

First of all, a general question regarding backlog IDs. In the General Template, IDs are specified as <backlog id>.<category>[.<chapter>.<topic>].<name> but in the examples and also in some contributions IDs are starting with STORY or EPIC, so what is the right format for backlogs IDs ?

 

Some other considerations:

 

Linked Data Approach

Some of the EPICs described (localization, object recognition in MMA) include creation of information. From our point of view it would be valuable if information generated would be as much linked as possible to widely adopted Linked Open Data Dataset such us Geonames or DBPedia. Thus, for example, localization could be provided also in terms of Geonames instances or monuments or people identified in a video could be linked to their DBPedia entries.

 

Publish / Subscribe functionality

Some of the EPICs described include the subscription to different events (changes in ontology, unusual occurrences in a video, etc).  I guess all this subscription functionality would be provided to users through the Pub / Subscribe broker. If so, I think it would be useful to include a little hint in the entries specifying so, and establishing that the work would consist in the integration between Pub / Subscribe broker and the given GE.

This also can be applied to querying functionality (story provided by TI in Semantic Annotation about SPARQL queries), that I guess would be provided to the user through the Query Broker.

 

Publish / Subscribe query language

The different stories about the Public / Subscribe query language are unclear to me. In two of them we are talking about defining a straightforward language, also optimized for mobile applications while in another one we are talking about allowing users to use their own language. Is this compatible?

 

From: fiware-data-bounces at lists.fi-ware.eu [mailto:fiware-data-bounces at lists.fi-ware.eu] On Behalf Of fano.ramparany at orange-ftgroup.com
Sent: jueves, 01 de septiembre de 2011 17:06
To: jhierro at tid.es; fiware-data at lists.fi-ware.eu
Cc: dany.cauchie at orange-ftgroup.com
Subject: Re: [Fiware-data] Peer review of Data/Context Management Backlogentries

 

Dear all,

 

Here are OLNC comments to the Backlog entries.

Talk to you at tomorrow confcall!

 

Fano

_________________________________________

 

FI-WARE Data Backlog Entries by Siemens (SiemensBacklog_v01.zip)

 

FI-WARE.Story.Data.MultimediaAnalysis.EventDetectionNotification

 

Description:

  <we propose to add:>

   " The communication mechanism used to send the notification events to application and the subscription protocol used by the application and the MMI event source should be based on well established standards."

 

_________________________________________

 

 

FI-WARE Data Backlog Entries by Thales (Backlog entries by Thales 11-08-25.xls)

 

FI-WARE.Epic.Data.LocalizationPlatform.AccessMngt

 

Description:

  <Open question: is some partner interested in developing or is there a need for in context dependent access policy (ex. "this" information is accessible at "that" time of the day", and filtering and obfuscation (ex. I'm ready to reveal my approximate position (for example the city I'm in) but not my exact position)>

 

_________________________________________

 

FI-WARE Data Backlog Entries by TI (Backlog entries by TI 22-08-11.xls)

 

STORY.FIWARE.Data.PublishSubscribe.QueryLanguage

Goal:

  <the current content is>

  "The query language shall be well defined and straighforward to the operations designed for publish/subscribe interface"

  <we propose to change it to:>

  "The query language shall be well defined and consistent with the Context and Data Elements format used by the Pub/Sub Broker."

 

Description:

  <the current description seems to apply to a query broker GE rather than to the pub/sub broker GE. so we propose to add:>

  "The query language shall allow the subscriber to specify the conditions for which it expects a notification from the broker as well as the content of the notification message. The conditions could include changes in the answer to the query, some logical conditions, matching of values or selection. The content of the notification message could include the answer to the query"

  <part of the last sentence is currently in the rationale section>

  <to elaborate on our suggested modification of the "Goal item", we propose also to add:>

  "As the Pub/Sub broker is flexible enough to support multiple content (data/context) formats (see the STORY.FIWARE.Data.PublishSubscribe.UpdateOperation User) the subscribing engine will be flexible enough to support the query language corresponding to the content format. for example if the content format is ContextML the query language will probably be based on CQL (Context Query Language). If the content format is RDF/OWL, the query language will probably be based on SPARQL."

 

_________________________________________

 

   

 

De : fiware-data-bounces at lists.fi-ware.eu [mailto:fiware-data-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro
Envoyé : lundi 29 août 2011 13:19
À : fiware-data at lists.fi-ware.eu
Objet : [Fiware-data] Peer review of Data/Context Management Backlog entries

 

Hi all,

  This mail is to officially launch the peer review of entries in the Data/Context Management Backlog.

  As I already told you, input received so far can be found under the FI-WARE Data Backlog folder/group in the docman system of the FI-WARE Data project in FusionForge.

  I would like ALL of you to carry out a peer review of the input produced by the rest of the team.   Please send your comments to the mailing list instead of me or the responsible of a particular GE.   Your comments are due by this friday September 2, EOB (IBM colleagues in Haifa can submit their comments also on Sunday September 4).   Goal is that we have all comments gathered at the start of next week and then work in the addressing received comments as to get a final version by end of that week, ready for investigation/discussion during our face2face meeting.

  As promised, here you are my overall comments on the entries received so far.    They are generic and intend to be just a first "meat to eat" so that you can start addressing some comments regarding entries you have submitted.   They are not applicable to all cases, of course.   T.I+D will provide specific comments in the above mentioned due date.

*	Try to stick to the formula proposed for goals in the example templates ("Applications should be able to ..." / "It should be possible ...").   This is common practice in Agile.   So, as far as it feasible, and not too much artificious, try to follow it.   Following a defined formula, we gain in uniformity but, overall it will be easier to extract <performed action>, <scenario> and <derived results>.   Note that in Agile, some people like to use a cannonical form which is "As a <role>, I can <activity> so that <business value>".   We tried just to adapt this a bit to description of stories for a software platform, but the notion of "cannonical form" itself is something we should try to stick to. 
*	Chapter field: should be "Data/Context Management" 
*	Source and Stakeholder fields:  You should write "FI-WARE" in here, at least for the time being.   Keep Source contact empty for the time being.
*	Owner and Owner contact: this should be the name of your company.   Fill the owner contact with your email for the time being but we'll see how to handle this later (we don't want that making entries publicly available becomes a source of spam :-)
*	We mentioned that "name" should be an acronymun (indeed the last part of the Id) but I have found itself a little bit useless itself if it is actually part of the Id.  Therefore, I suggest that we follow the approach of Thales and use it as a short description (should not be longer than 7 words, preferably 4-5 excluding "and"s "the"s and similar auxiliary articles, prepositions, etc) 
*	The Description field is free.   Put there whatever makes sense to you and would be helpful to understand the entry.   Don't hesitate to add URLs to complementary documents, standards, whatever you believe may be useful if read.   You can upload a document to the docman system at FusionForge and then use the link if you wish. 
*	Regarding the Rationale: at least for entries prioritized with a MUST MoSCoW, try to give more info about why "it would have no sense" if we do not develop the corresponding feature.   Note that a MUST priority is considered to be assigned for features that "If not done, the project will be considered a failure".  In other words: the product doesn't make sense to you unless it supports that feature.   UC projects may argue that some of the features they propose are going to be of a higher priority than these ones, so that better you work the rationale for keeping your priority.
*	About the MoSCoW priority:   It is assumed that you are bringing here an asset that your company had developed and had plans to keep evolving because it is of relevant priority to you.   Therefore, here you are some guidelines that I would suggest you to bear in mind when reviewing the MoSCoW priorities you had assigned. 

	*	You should assign a MUST priority to features you would plan to address in the following 12 months in your product, no matter whether FI-WARE had existed or not.   Again, the product doesn't make sense if you are not allowed to address this MUST priority 
	*	You may assign a SHOULD priority to features that were in your roadmap and you believe were important although perhaps you couldn't address them in the next 12 months prior existence of FI-WARE because lack of resources.  FI-WARE actually gaves you the opportunity to address them. 
	*	You should assign a COULD priority to features you believe are nice to have and could be addressed thanks to FI-WARE.    But are open to learn about better ideas that may get assigned a higher priority. 

  
  Hope all these comments become useful.

  Don't hesitate to formulate any question.

  Best regards,

-- Juanjo

________________________________

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

------------------------------------------------------------------
This e-mail and the documents attached are confidential and intended 
solely for the addressee; it may also be privileged. If you receive 
this e-mail in error, please notify the sender immediately and destroy it. 
As its integrity cannot be secured on the Internet, the Atos 
group liability cannot be triggered for the message content. Although 
the sender endeavours to maintain a computer virus-free network, 
the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. 

Este mensaje y los ficheros adjuntos pueden contener informacion confidencial 
destinada solamente a la(s) persona(s) mencionadas anteriormente 
pueden estar protegidos por secreto profesional. 
Si usted recibe este correo electronico por error, gracias por informar 
inmediatamente al remitente y destruir el mensaje. 
Al no estar asegurada la integridad de este mensaje sobre la red, Atos 
no se hace responsable por su contenido. Su contenido no constituye ningun 
compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. 
Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor 
no puede garantizar nada al respecto y no sera responsable de cualesquiera 
danos que puedan resultar de una transmision de virus. 
------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110902/861fc873/attachment.html>