<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Dear Bruno, all, <br>
<br>
this mail answers to your comments from two different perspective:<br>
<br>
1) <b>technological aspects</b><br>
I'm very happy you have experience with two different ZB development
kits. It will be very useful, we can discus about this off-line or
through the proper mailing lists of the project .<br>
<br>
I don't agree with your recommendation. Let me explain better the
goal of our project.<br>
I would like to achieve a separation of concerns as far as ontology
definition is concerned.<br>
I attached a picture representing the three-layered model we had in
PERSONA.<br>
I think you can easily read the picture representing SAIL (Sensor
Abstraction and Integration Layer) sub-project of PERSONA.<br>
It was implemented on OSGi, and only the top most layer concerns
with the <b>integration </b>of a specific technology.<br>
As example, there are two components depicted in the picture, one is
the the bundle that maps ZB to the UPnP Specification, the second
exports the interfaces according to PERSONA architecture, that' s by
using the PERSONA ontology.<br>
Our project wont deal with the <b>Integration Layer</b>, but only
with the first two layer: Access and Abstraction Layer.<br>
<br>
IMO there are at least two good reasons for such approach.<br>
a)There are many ontology definitions out there, not only OSGi4AMI,
but PERSONA, OASIS and standards like ISO11073 ...<br>
So we need to create consensus, and the ZB4OSGI project is not the
right place to do it.<br>
<br>
b) We want to be free to provide a very good solution for ZigBee,
independently from the strategic objectives of AALOA.<br>
In such way we can assure that other communities will test our
software and will contribute to the bug fixing.<br>
AALOA in other projects will be able to reuse the ZB4OSGi results
according to a shared plan.<br>
<br>
2)<b> Organisational aspects</b><br>
The federation of projects is an important aspect we introduced in
the AALOA Manifesto: the glue thanks to which this community is
growing.<br>
I quoted here the "Call for Project Proposal" of the Manifesto:<br>
<br>
"The association will be organised as a federation of<br>
projects, one representative of each project being a<br>
member of the Governing Board.<br>
Proposals for new projects can be submitted to the<br>
Governing Board, whose main role will be their<br>
evaluation with respect to the association’s mission,<br>
<b>while still encouraging the emergence of diversity, and<br>
avoiding monoculture</b>. <b>Projects will autonomously<br>
organize their governance rules</b>. Over time common<br>
rules suggested by practice may be formally adopted... "<br>
<br>
It is to point out that we should mainly vote regarding the
usefulness of the project, but we cannot bind the vote to the
realization of specific goals of AALOA.<br>
In theory committers of open source projects are volunteers.<br>
The project leader can report the advises he receive during the
board meeting, but usually he has not the power to impose "external"
decisions.<br>
They must be discussed and accepted by the community working in the
project according to their internal organization.<br>
<br>
The coordination and the mutual commitments we can reach in AALOA
is another matter.<br>
We can create ad hoc projects for shared objectives after discussing
among interested members .<br>
I see your request/recommendation in this way. For example, we can
start to discuss about AAL ontologies in a specific project promoted
by EU projects like OASIS, UniversAAL, MonAMI and incubated by
AALOA... Alternatively also single organizations (e.g the CNR and
Trialog) could decide to dedicate resources to a specific project of
mutual interest.<br>
<br>
However the AALOA converging process to a common platform has not to
influence the project proposals submitted to AALOA.<br>
The first level of aggregation in AALOA is to allow visibility of
all the AAL-related software.<br>
In this way EU projects/ organizations /individuals may be
interested to enter in AALOA.<br>
The sharing of common objectives and planning is a second step.<br>
I think it is the real challenge we have as community. <br>
We need to be able to take commitments as a single entity, but also
to be free to propose independent solutions.<br>
Working both as an Industrial Alliance that addresses specific
targets, and as an Open Source Community that encourages the
diversity.<br>
<br>
We are a community of communities, the challenge is to find the
right alchemy to work all together in harmony (it sounds good at
Christmas ;-) ) <br>
<br>
Said that, I took your message as excuse to talk about these issues.
<br>
I will happy (and curious) to discuss with you about the MonAMI
interfaces ;-)<br>
<br>
BRs,<br>
Francesco<br>
<br>
<br>
<br>
<br>
<br>
Il 21/12/2010 9.48, Bruno Jean-Bart ha scritto:
<blockquote cite="mid:4D1069E2.9000707@trialog.com" type="cite">
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
Dear Francesco and all,<br>
My vote will be provided in a separate email but I include here
remarks on the Zigbee driver project.<br>
<br>
As already mentionned by Antonio (Trialog) and Roberto (Uni.
Zaragoza), we have developed in MonAMI two drivers for Zigbee
Wireless Sensors network, one by Unv Zaragoza, one by Trialog. The
two approaches use different Zigbee implementation (Ember for
Uzaz) and (TI for TRIALOG). The objectives of these two approaches
were twofold : <br>
<br>
1. to proof that the OSGi4AMI interfaces (Application Interfaces
representing sensors and actuators independantly from the type of
the network) can be implemented easily by two different teams. <br>
<br>
2. to validate that the OSGi4AMI interfaces are comprehensively
defined to enable the interoperability of applications.<br>
<br>
The objective 1 was demonstrated. <br>
The objective 2 shows in some cases that the key issues is there :
an application interface such as OSGI4AMI is a must for
interoperability of applications but this is not sufficient: for
interoperability, the behaviour of devices themselves are
generally not totally identical and therefore the driver shall
take into account these differences.<br>
<br>
In your project, I see some proposals to take into the above
issues : The use of the Zigbee Cluster Library will help for
interoperability at the level of Application Interfaces. However
for AALOA, one of the primary objectives is the definition of the
Application interfaces of the drivers. This interface cannot be
the Zigbee-based on the ZCL, but something more generic and I do
not see that approach in your document.<br>
<br>
Therefore I would recommend the AALOA board to vote for the Zigbee
Project but a first task of this project would be to define the
Device API. In that goal, I recommend to use as input the OSGi4AMI
proposal (note that this name is misleading : the OSGI4AMI
interfaces are not depending on OSGi, nor Java. This is mainly an
ontology of devices, then mapped into Java interfaces).<br>
<br>
Bruno <br>
<pre class="moz-signature" cols="72">_________________________________________________________________________
Bruno Jean-Bart
Connectivity Products & Services
TRIALOG, 25 rue du General Foy, F-75008 Paris - France
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.trialog.com">http://www.trialog.com</a>
Tel Direct : (33 1) 44 70 61 08, Fax :(33 1) 44 70 05 91
_________________________________________________________________________
</pre>
<br>
Le 16/12/2010 15:07, Francesco Furfari a écrit :
<blockquote cite="mid:4D0A1D24.8060809@isti.cnr.it" type="cite"> Dear
Supporters, <br>
<br>
today I submitted a first project proposal to the Governing
Board of AALOA. <br>
Even if the project was already announced, it was a needed
action in order to define the process for submitting a project
proposal. <br>
The governig board will decide whether the project proposal is
alligned to the AALOA mission and consequently will allocate the
requested resources. <br>
<br>
In particular this proposal is one of the outcomes of the
PERSONA project (<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.aal-persona.org/">http://www.aal-persona.org/</a>)
that finished with excellent evaluation few days ago. <br>
As described in the Manifesto the leader proposing the project
will be part of the AALOA Governing Board. <br>
<br>
We don't have a formal proposal template so far. <br>
I thought to the following sections: <br>
1. Motivation for incubating the project <br>
2. Description of the codebase or the input material for the
project <br>
3. Simple roadmap and invitation to contribute ( how the AALOA
community could help) <br>
4. People involved (e.g. the list of initial committers in case
of software projects) <br>
5. An optional expression of interest on the project incubation.
( list of people internal or external to AALOA ) <br>
<br>
I invite all of you to read the proposal for the ZigBee 4 OSGi
project, <br>
help to advertise the project (when accepted) and help to
contribute to the further development and testing. <br>
<br>
Please, if you have any doubt about project proposal
submission, don't hesitate to post your questions, <br>
they will help to create a FAQ on the topic. <br>
<br>
Kind regards, <br>
Francesco <br>
<br>
<br>
<br>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Supporters mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Supporters@aaloa.org">Supporters@aaloa.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://aaloa.org/mailman/listinfo/supporters">http://aaloa.org/mailman/listinfo/supporters</a>
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>