<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Dear Kai,<br>
    <br>
    this is a very good news.<br>
    We will be happy to contribute to the requirements,<br>
    as well as to work on the reference implementation when the
    specification will be ready.<br>
    <br>
    Concerning Z-Wave I tried time ago to get their specification but it
    wasn't open.<br>
    Is there anybody in AALOA who have experience with such technology ?<br>
    <br>
    Kind regards,<br>
    Francesco<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    Il 22/12/2010 11.07, Kai Hackbarth ha scritto:
    <blockquote
      cite="mid:E8B119DC-52B3-43F5-B055-3B7DC157131B@prosyst.com"
      type="cite">Dear Francesco, all,
      <div><br>
      </div>
      <div>some of you may know that the OSGi Residential Expert Group
        started to work on new requirements for REG specification
        release 5. We are also planning to define standardized APIs for
        ZigBee and Z-Wave. The general idea that Francesco introduced is
        inline with what are planning to do at REG. We will start
        working on requirements documents next year and you kindly
        invited to participate in this activities. I keep you informed.</div>
      <div><br>
      </div>
      <div>Regards,</div>
      <div>Kai</div>
      <div><br>
      </div>
      <div><br>
        <div>
          <div>Am 21.12.2010 um 20:00 schrieb Francesco Furfari:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <div 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"> 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>
            </div>
            <span><ZigBee.JPG></span>_______________________________________________<br>
            Supporters mailing list<br>
            <a moz-do-not-send="true" href="mailto:Supporters@aaloa.org">Supporters@aaloa.org</a><br>
            <a class="moz-txt-link-freetext" href="http://aaloa.org/mailman/listinfo/supporters">http://aaloa.org/mailman/listinfo/supporters</a><br>
          </blockquote>
        </div>
        <br>
        <div>
          <span class="Apple-style-span" style="border-collapse:
            separate; color: rgb(0, 0, 0); font-family: Helvetica;
            font-style: normal; font-variant: normal; font-weight:
            normal; letter-spacing: normal; line-height: normal;
            orphans: 2; text-indent: 0px; text-transform: none;
            white-space: normal; widows: 2; word-spacing: 0px;
            font-size: medium;">-------------------------------------------------------------------------------------------------<br>
            Kai Hackbarth · Evangelist & Chair OSGi Residential
            Expert Group<br>
            ProSyst Software GmbH<br>
            D-50858 Cologne, Germany . Dürener Strasse 405<br>
            Tel. +49 (0)221 6604 410 · Fax  +49 (0)221 6604 660<br>
            Mobile +49 (0)163 6604 410 · US Mobile +1-317-6039-264<br>
            <a moz-do-not-send="true" href="http://www.prosyst.com">http://www.prosyst.com</a>
            · <a moz-do-not-send="true"
              href="mailto:k.hackbarth@prosyst.com">k.hackbarth@prosyst.com</a><br>
-------------------------------------------------------------------------------------------------<br>
            stay in touch with your product.<br>
-------------------------------------------------------------------------------------------------<br>
            <br>
            <br>
          </span>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>