Hi, I would love to get very concrete and clear feedback on the NGI GEs from FI-WARE. We are having a Architecture Board meeting next week and I could put this on that agenda still. As you know a lot of people see 3D worlds and IoT as a perfect combination and want to see things happening. So we should tell them how to improve things to make it possible/easier. Maybe you can set up a Google doc where we summarize this? Best, Philipp Am 25.10.2013 10:34, schrieb Tomi Sarni: > Yes I agree in general. Just a thought that in some use-cases this > could be thought as an option. It has been difficult to design the API > in a way that it would be highly dynamic in a sense that it would suite > wide variety of application development needs. > The NGSI 9/10 > <http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/NGSI-9/NGSI-10_information_model> > development in earlier GE seemed difficult to adapt and in my personal > opinnion does allow passing interaction interface clearly enough for the > application developer. > > > On Fri, Oct 25, 2013 at 11:28 AM, Philipp Slusallek > <Philipp.Slusallek at dfki.de <mailto:Philipp.Slusallek at dfki.de>> wrote: > > Hi, > > With interaction I mean the user interaction. Yes, it eventually > gets mapped to REST (or such) calls to the device. But how you map > the device functionality to user interaction is a big step where > different applicatios will have very different assumptions and > interaction metaphors. Mapping them all to ageneric sensor model > seems very difficult. > > Using a sematic annotation avoid having to create such a mapping > when you design the sensor, avoid having to store the model on each > sonsor, and pushes the mapping to the software/application > side,which is (in my opinion) in a much better option to decide on > that mapping. A fallback mapping may still be provided by the sensor > for the most basic cases. > > > Best, > > Philipp > > Am 25.10.2013 09:05, schrieb Tomi Sarni: > > /It becomes more of an issue when we talk about interactivity, > when the > > visual representation needs to react to user input in a way that is > consistent with the application and calls functionality in the > application. In other words, you have to do a mapping from the > sensor to > the application at some point along the pipeline (and back for > actions > to be performed by an actuator)./ > > > Currently when a client polls a device(containing sensor and/or > actuators) it will receive all interaction options that > available for > the particular sensor or actuator. These options can be then > accessed > by a HTTP POST method from the service. So there is the logical > mapping. > I can see your point though, in a way it would seem logical to > have that > XML3D model to contain states (e.g. button up and button down 3d > model > states), and i have no idea whether this is supported by XML3D, as i > have been busy on server/sensor side. This way when a sensor is > being > accesses by HTTP POST call to change state to either on or off for > instance, the XML3D model could contain transition logic to change > appearance from one state to another. Alternatively there can be two > models for two states. When the actuator is being queried it > will return > model that corresponds to its current state. > > > > > > On Fri, Oct 25, 2013 at 9:29 AM, Philipp Slusallek > <Philipp.Slusallek at dfki.de <mailto:Philipp.Slusallek at dfki.de> > <mailto:Philipp.Slusallek at __dfki.de > <mailto:Philipp.Slusallek at dfki.de>>> wrote: > > Hi Tomi, > > Yes, this is definitely an interesting option and when > sensors offer > REST-ful interfaces, it should be almost trivial to add (once a > suitable and standardized way of how to find that data is > specified. > At least it would provide a kind of default visualization > in case no > other is available. > > It becomes more of an issue when we talk about > interactivity, when > the visual representation needs to react to user input in a > way that > is consistent with the application and calls functionality > in the > application. In other words, you have to do a mapping from the > sensor to the application at some point along the pipeline > (and back > for actions to be performed by an actuator). > > Either we specify the sensor type through some semantic > means (a > simple tag in the simplest case, a full RDF/a graph in the best > case) and let the application choose how to represent it or > we need > to find a way to map generic behavior of a default object to > application functionality. The first seems much easier to me as > application functionality is likely to vary much more than > sensor > functionality. And semantic sensor description have been > worked on > for a long time and are available on the market. > > Of course, there are hybrid methods as well: A simple one > would be > to include a URI/URL to a default model in the semantic sensor > description that then gets loaded either from the sensor > through > REST (given some namespace there) or via the Web (again > using some > namespace or search strategy). Then the application can always > inject its own mapping to what it thinks is the best mapping. > > > Best, > > Philipp > > Am 25.10.2013 07:52, schrieb Tomi Sarni: > > *Following is completely on theoretical level:* > > To mix things a little further i've been thinking about a > possibility to > store visual representation of sensors within the sensors > themselves. > Many sensor types allow HTTP POST/GET or even > PUT/DELETE methods > (wrapped in SNMP/CoAP communication protocols for > instance) which in > theory would allow sensor subscribers to also publish > information in > sensors (e.g. upload an xml3d model). This approach > could be > useful in > cases where these sensors would have different purposes > of use. > But the > sensor may have very little space to use for the model > from up > 8-18 KB. > Also the web service can attach the models to IDs > through use of > data > base. This is really just a pointer, perhaps there would be > use-cases > where the sensor visualization could be stored within > the sensor > itself, > i think specifically some AR solutions could benefit > from this. > But do > not let this mix up things, this perhaps reinforces the > fact > that there > need to be overlaying middleware services that attach > visual > representation based on their own needs. One service > could use > different > 3d representation for temperature sensor than another one. > > > > > On Thu, Oct 24, 2013 at 9:49 PM, Philipp Slusallek > <Philipp.Slusallek at dfki.de > <mailto:Philipp.Slusallek at dfki.de> > <mailto:Philipp.Slusallek at __dfki.de > <mailto:Philipp.Slusallek at dfki.de>> > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@>__df__ki.de <http://dfki.de> > <mailto:Philipp.Slusallek at __dfki.de > <mailto:Philipp.Slusallek at dfki.de>>>> wrote: > > Hi, > > OK, now I get it. This does make sense -- at least > in a local > scenario, where the POI data (in this example) > needs to be > stored > somewhere anyway and storing it in a component and > then > generating > the appropriate visual component does make sense. > Using web > components or a similar mechanism we could > actually do the > same via > the DOM (as discussed for the general ECA sync > before). > > But even then you might actually not want to store > all the > POI data > but only the part that really matter to the > application > (there may > be much more data -- maybe not for POIs but > potentially for > other > things). > > Also in a distributed scenario, I am not so sure. > In that > case you > might want to do that mapping on the server and > only sync the > resulting data, maybe with reference back so you > can still > interact > with the original data through a service call. > That is the main > reason why I in general think of POI data and POI > representation as > separate entities. > > Regarding terminology, I think it does make sense to > differntiate > between the 3D scene and the application state > (that is not > directly > influencing the 3D rendering and interaction). > While you > store them > within the same data entity (but in different > components), they > still refer to quite different things and are > operated on by > different parts of you program (e.g. the renderer > only ever > touches > the "scene" data). We do the same within the XML3D > core, > where we > attach renderer-specific data to DOM nodes and I > believe > three.js > also does something similar within its data > structures. At > the end, > you have to store these things somewhere and there > are only > so many > way to implement it. The differences are not > really that big. > > > Best, > > Philipp > > Am 24.10.2013 19:24, schrieb Toni Alatalo: > > On 24 Oct 2013, at 19:24, Philipp Slusallek > <Philipp.Slusallek at dfki.de > <mailto:Philipp.Slusallek at dfki.de> > <mailto:Philipp.Slusallek at __dfki.de > <mailto:Philipp.Slusallek at dfki.de>> > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@>__df__ki.de <http://dfki.de> > <mailto:Philipp.Slusallek at __dfki.de > <mailto:Philipp.Slusallek at dfki.de>>> > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@> > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@>>__d__f__ki.de <http://df__ki.de> > <http://dfki.de> > > > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@>__df__ki.de <http://dfki.de> > <mailto:Philipp.Slusallek at __dfki.de > <mailto:Philipp.Slusallek at dfki.de>>>>> wrote: > > Good discussion! > > > I find so too — thanks for the questions and > comments > and all! Now > briefly about just one point: > > Am 24.10.2013 17:37, schrieb Toni Alatalo: > > integrates to the scene system too - for > example if a > scene server > queries POI services, does it then > only use the > data to > manipulate > the scene using other non-POI > components, or > does it > often make sense > also to include POI components in the > scene so > that the > clients get > it too automatically with the scene > sync and > can for > example provide > POI specific GUI tools. Ofc clients > can query POI > services directly > too but this server centric setup is > also one > scenario > and there the > scene integration might make sense. > > But I would say that there is a clear > distinction > between > the POI data > (which you query from some service) and the > visualization or > representation of the POI data. Maybe you > are more > talking > about the > latter here. However, there really is an > application > dependent mapping > from the POI data to its representation. Each > application > may choose > to present the same POI data in very > different way > and its > only this > resulting representation that becomes part > of the > scene. > > > No I was not talking about visualization or > representations here > but the > POI data. > > non-POI in the above tried to refer to the > whole which > covers > visualisations etc :) > > Your last sentence may help to understand the > confusion: in > these posts > I’ve been using the reX entity system > terminology only > — hoping > that it > is clear to discuss that way and not mix terms > (like > I’ve tried > to do in > some other threads). > > There ‘scene’ does not refer to a visual / > graphical or any > other type > of scene. It does not refer to e.g. something > like what > xml3d.js and > three.js, or ogre, have as their Scene objects. > > It simply means the collection of all > entities. There it is > perfectly > valid to any kind of data which does not end > up to e.g. the > visual scene > — many components are like that. > > So in the above ‘only use the data to > manipulate the > scene using > other > non-POI components’ was referring to for example > creation of Mesh > components if some POI is to be visualised > that way. > The mapping > that > you were discussing. > > But my point was not about that but about the > POI data > itself — > and the > example about some end user GUI with a widget that > manipulates > it. So it > then gets automatically synchronised along > with all the > other > data in > the application in a collaborative setting etc. > > Stepping out of the previous terminology, we > could perhaps > translate: > ‘scene’ -> ‘application state’ and ‘scene > server’ -> > ‘synchronization > server’. > > I hope this clarifies something — my apologies > if not.. > > Cheers, > ~Toni > > P.S. i sent the previous post from a foreign > device and > accidentally > with my gmail address as sender so it didn’t > make it to > the list > — so > thank you for quoting it in full so I don’t > think we > need to > repost that :) > > This is essentially the Mapping stage of > the well-known > Visualization > pipeline > > > (http://www.infovis-wiki.net/______index.php/Visualization_______Pipeline > <http://www.infovis-wiki.net/____index.php/Visualization_____Pipeline> > > <http://www.infovis-wiki.net/____index.php/Visualization_____Pipeline > <http://www.infovis-wiki.net/__index.php/Visualization___Pipeline>> > > > > <http://www.infovis-wiki.net/____index.php/Visualization_____Pipeline > <http://www.infovis-wiki.net/__index.php/Visualization___Pipeline> > <http://www.infovis-wiki.net/__index.php/Visualization___Pipeline <http://www.infovis-wiki.net/index.php/Visualization_Pipeline>>>), > > except > that here we also map interaction aspects > to an > abstract scene > description (XML3D) first, which then > performs the > rendering and > interaction. So you can think of this as > an additional > "Scene" stage > between "Mapping" and "Rendering". > > I think this is a different topic, but > also with > real-virtual > interaction for example how to > facilitate nice > simple > authoring of > the e.g. real-virtual object mappings > seems a > fruitful > enough angle > to think a bit, perhaps as a case to > help in > understanding the entity > system & the different servers etc. > For example > if there's a > component type 'real world link', the > Interface > Designer > GUI shows it > automatically in the list of > components, ppl > can just > add them to > their scenes and somehow then the > system just > works.. > > > I am not sure what you are getting at. But > it would > be great > if the > Interface Designer would allow to choose > such POI > mappings > from a > predegined catalog. It seems that Xflow > can be used > nicely for > generating the mapped scene elements from some > input data, > e.g. using > the same approach we use to provide basic > primitives like > cubes or > spheres in XML3D. Here they are not fixed, > build-in > tags as > in X3D but > can actually be added by the developer as > it best fits. > > For generating more complex subgraphs we > may have > to extend the > current Xflow implementation. But its at > least a great > starting point > to experiment with it. Experiments and > feedback > would be > very welcome > here. > > I don't think these discussions are > now hurt by us > (currently) having > alternative renderers - the entity system, > formats, sync > and the > overall architecture is the same anyway. > > > Well, some things only work in one and > others only > in the other > branch. So the above mechanism could not > be used to > visualize POIs in > the three.js branch but we do not have all the > features to > visualize > Oulu (or whatever city) in the XML3D.js > branch. This > definitely IS > greatly limiting how we can combine the > GEs into > more complex > applications -- the untimate goal of the > orthogonal > design > of this > chapter. > > And it does not even work within the same > chapter. > It will > be hard to > explain to Juanjo and others from FI-WARE > (or the > commission > for that > matter). > > BTW, I just learned today that there is a > FI-WARE > smaller review > coming up soon. Let's see if we already > have to present > things there. > So far they have not explicitly asked us. > > > Best, > > Philipp > > -Toni > > > From an XML3D POV things could > actually be > quite > "easy". It should > be rather simple to directly > interface to > the IoT > GEs of FI-WARE > through REST via a new Xflow > element. This > would > then make the data > available through <data> elements. > Then you > can use > all the features > of Xflow to manipulate the scene > based on > the data. > For example, we > are discussing building a set of > visualization nodes > that implement > common visualization metaphors, > such as scatter > plots, animations, > you name it. A new member of the lab > starting soon > wants to look > into this area. > > For acting on objects we have > always used Web > services attached to > the XML3D objects via DOM events. > Eventually, I > believe we want a > higher level input handling and > processing > framework > but no one > knows so far, how this should look > like (we > have > some ideas but they > are not well baked, any inpu is > highly welcome > here). This might or > might not reuse some of the Xflow > mechanisms. > > But how to implement RealVirtual > Interaction is > indeed an intersting > discussion. Getting us all on the > same page and > sharing ideas and > implementations is very helpful. > Doing this > on the > same SW platform > (without the fork that we > currently have) would > facilitate a > powerful implementation even more. > > > Thanks > > Philipp > > Am 23.10.2013 08:02, schrieb Tomi > Sarni: > > ->Philipp > /I did not get the idea why > POIs are > similar to > ECA. At a very high > level I see it, but I am not > sure what > it buys > us. Can someone sketch > that picture in some more detail?/ > > Well I suppose it becomes > relevant at > point when > we are combining our > GEs together. If the model can be > applied in > level of scene then > down to > POI in a scene and further down in > sensor level, > things can be > more easily visualized. Not > just in > terms of > painting 3D models but in > terms of handling big data as > well, more > specifically handling > relationships/inheritance. It also > makes it easier > to design a RESTful API as we > have a common > structure which to follow > and also provides more > opportunities > for 3rd > party developers to make > use of the data for their own > purposes. > > For instance > > ->Toni > > From point of sensors, the > entity-component becomes > device-sensors/actuators. A > device may > have an > unique identifier and IP > by which to access it, but it > may also > contain > several actuators and > sensors > that are components of that > device entity. > Sensors/actuators > themselves > are not aware to whom they are > interesting to. > One client may use the > sensor information differently > to other > client. > Sensor/actuator service > allows any other service to > query using > request/response method either > by geo-coordinates > (circle,square or > complex > shape queries) or perhaps > through type+maxresults and > service > will return > entities and their > components > from which the reqester can > form logical > groups(array of entity uuids) > and query more detailed > information > based on > that logical group. > > I guess there needs to be similar > thinking done > on POI level. I guess > POI does not know which scene it > belongs to. It > is up to scene > server to > form a logical group of POIs (e.g. > restaurants > of oulu 3d city > model). Then > again the problem is that > scene needs > to wait > for POI to query for > sensors and form its logical > groups > before it > can pass information to > scene. This can lead to long wait > times. But > this sequencing problem is > also something > that could be thought. Anyways > this is > a common > problem with everything > in web at the moment in my > opinnion. > Services > become intertwined. > When a > client loads a web page there > can be > queries to > 20 different services > for advertisment and other > stuff. Web page > handles it by painting stuff > to the client on receive > basis. I think > this > could be applied in Scene > as well. > > > > > > On Wed, Oct 23, 2013 at 8:00 AM, > Philipp Slusallek > <Philipp.Slusallek at dfki.de > <mailto:Philipp.Slusallek at dfki.de> > <mailto:Philipp.Slusallek at __dfki.de > <mailto:Philipp.Slusallek at dfki.de>> > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@>__df__ki.de <http://dfki.de> > <mailto:Philipp.Slusallek at __dfki.de > <mailto:Philipp.Slusallek at dfki.de>>> > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@> > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@>>__d__f__ki.de <http://df__ki.de> > <http://dfki.de> > > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@>__df__ki.de <http://dfki.de> > <mailto:Philipp.Slusallek at __dfki.de > <mailto:Philipp.Slusallek at dfki.de>>>> > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@> > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@>>__d__f__ki.de <http://df__ki.de> > <http://dfki.de> > > > <mailto:Philipp.Slusallek@ > <mailto:Philipp.Slusallek@>__df__ki.de <http://dfki.de> > <mailto:Philipp.Slusallek at __dfki.de > <mailto:Philipp.Slusallek at dfki.de>>>>> wrote: > > Hi, > > First of all, its > certainly a good > thing to > also meet locally. I was > just a bit confused > whether that > meeting > somehow would involve us as > well. Summarizing the results > briefly for > the others would > definitely be interesting. > > I did not get the idea why > POIs are > similar > to ECA. At a very high > level I see it, but I am > not sure > what it > buys us. Can someone > sketch that picture in > some more > detail? > > BTW, what is the status > with the > Rendering > discussion (Three.js vs. > xml3d.js)? I still have > the feeling > that we > are doing parallel work > here that should probably > be avoided. > > BTW, as part of our > shading work > (which is > shaping up nicely) Felix > has been looking lately at > a way to > describe > rendering stages > (passes) essentially > through Xflow. > It is > still very experimental > but he is using it to > implement > shadow maps > right now. > > @Felix: Once this has > converged > into a bit > more stable idea, it > would be good to post this > here to get > feedback. The way we > discussed it, this > approach could > form a > nice basis for a modular > design of advanced > rasterization > techniques > (reflection maps, adv. > face rendering, SSAO, lens > flare, tone > mapping, etc.), and (later) > maybe also describe global > illumination > settings (similar to our > work on LightingNetworks > some years > ago). > > > Best, > > Philipp > > Am 22.10.2013 23:03, schrieb > toni at playsign.net <mailto:toni at playsign.net> > <mailto:toni at playsign.net <mailto:toni at playsign.net>> > <mailto:toni at playsign.net <mailto:toni at playsign.net> > <mailto:toni at playsign.net <mailto:toni at playsign.net>>> > <mailto:toni at playsign.net > <mailto:toni at playsign.net> > <mailto:toni at playsign.net <mailto:toni at playsign.net>> > <mailto:toni at playsign.net > <mailto:toni at playsign.net> > <mailto:toni at playsign.net <mailto:toni at playsign.net>>>> > > <mailto:toni at playsign.net > <mailto:toni at playsign.net> > <mailto:toni at playsign.net <mailto:toni at playsign.net>> > <mailto:toni at playsign.net > <mailto:toni at playsign.net> > <mailto:toni at playsign.net <mailto:toni at playsign.net>>>>: > > Just a brief note: we > had some > interesting preliminary > discussion > triggered by how the data > schema that > Ari O. presented for > the POI > system seemed at least > partly > similar to > what the Real-Virtual > interaction work had > resulted > in too -- > and in fact about > how the > proposed POI schema > was basically a > version of the > entity-component > model which we’ve > already been > using for > scenes in realXtend > (it is > inspired by / modeled > after it, Ari > told). So it can be much > related to > the Scene API work in the > Synchronization GE too. As the > action > point we > agreed that Ari will > organize a > specific > work session on that. > I was now thinking that it > perhaps at > least partly leads > back to the > question: how do we > define (and > implement) component types. I.e. > what > was mentioned in that > entity-system post > a few weeks back (with > links > to reX IComponent > etc.). I mean: if > functionality such as > POIs and > realworld interaction > make sense as > somehow resulting in > custom data > component types, does > it mean > that a key > part of the framework > is a way > for those systems to > declare > their types > .. so that it > integrates nicely > for the whole we want? > I’m not > sure, too > tired to think it > through now, > but anyhow just wanted to > mention that > this was one topic that > came up. > I think Web Components > is again > something to check - as in XML > terms reX > Components are xml(3d) > elements > .. just > ones that are usually in > a group > (according to the reX > entity > <-> xml3d > group mapping). And Web > Components are about > defining & > implementing new elements > (as Erno > pointed out in a different > discussion > about xml-html authoring > in the > session). > BTW Thanks Kristian > for the great > comments in that entity system > thread - was really > good to > learn about > the alternative > attribute access > syntax and the > validation in > XML3D(.js). > ~Toni > P.S. for (Christof &) > the DFKI > folks: > I’m sure you > understand the > rationale of these > Oulu meets > -- idea is > ofc not to exclude you > from the > talks but just makes > sense for > us to > meet live too as we are in > the same > city afterall etc -- > naturally > with the > DFKI team you also talk > there > locally. Perhaps is a > good idea > that we > make notes so that can > post e.g. > here then (I’m not > volunteering > though! > 😜) . Also, the now > agreed > bi-weekly setup on > Tuesdays luckily > works so that we can then > summarize > fresh in the global Wed > meetings and > continue the talks etc. > *From:* Erno Kuusela > *Sent:* Tuesday, > October > 22, 2013 > 9:57 AM > *To:* Fiware-miwi > > > Kari from CIE offered > to host > it this > time, so see you there at > 13:00. > > Erno > > > _______________________________________________________ > > > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>> > > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>>> > > <mailto:Fiware-miwi at lists.fi-______ware.eu > <mailto:Fiware-miwi at lists.fi-____ware.eu> > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu>> > > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>>>> > > <mailto:Fiware-miwi at lists.fi-______ware.eu > <mailto:Fiware-miwi at lists.fi-____ware.eu> > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu>> > > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>>>> > https://lists.fi-ware.eu/________listinfo/fiware-miwi > <https://lists.fi-ware.eu/______listinfo/fiware-miwi> > <https://lists.fi-ware.eu/______listinfo/fiware-miwi > <https://lists.fi-ware.eu/____listinfo/fiware-miwi>> > > <https://lists.fi-ware.eu/______listinfo/fiware-miwi > <https://lists.fi-ware.eu/____listinfo/fiware-miwi> > <https://lists.fi-ware.eu/____listinfo/fiware-miwi > <https://lists.fi-ware.eu/__listinfo/fiware-miwi>>> > > > <https://lists.fi-ware.eu/______listinfo/fiware-miwi > <https://lists.fi-ware.eu/____listinfo/fiware-miwi> > <https://lists.fi-ware.eu/____listinfo/fiware-miwi > <https://lists.fi-ware.eu/__listinfo/fiware-miwi>> > <https://lists.fi-ware.eu/____listinfo/fiware-miwi > <https://lists.fi-ware.eu/__listinfo/fiware-miwi> > <https://lists.fi-ware.eu/__listinfo/fiware-miwi > <https://lists.fi-ware.eu/listinfo/fiware-miwi>>>> > > > > > _______________________________________________________ > > > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>> > > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>>> > > <mailto:Fiware-miwi at lists.fi-______ware.eu > <mailto:Fiware-miwi at lists.fi-____ware.eu> > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu>> > > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>>>> > > <mailto:Fiware-miwi at lists.fi-______ware.eu > <mailto:Fiware-miwi at lists.fi-____ware.eu> > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu>> > > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>>>> > https://lists.fi-ware.eu/________listinfo/fiware-miwi > <https://lists.fi-ware.eu/______listinfo/fiware-miwi> > <https://lists.fi-ware.eu/______listinfo/fiware-miwi > <https://lists.fi-ware.eu/____listinfo/fiware-miwi>> > <https://lists.fi-ware.eu/______listinfo/fiware-miwi > <https://lists.fi-ware.eu/____listinfo/fiware-miwi> > <https://lists.fi-ware.eu/____listinfo/fiware-miwi > <https://lists.fi-ware.eu/__listinfo/fiware-miwi>>> > > > > <https://lists.fi-ware.eu/______listinfo/fiware-miwi > <https://lists.fi-ware.eu/____listinfo/fiware-miwi> > <https://lists.fi-ware.eu/____listinfo/fiware-miwi > <https://lists.fi-ware.eu/__listinfo/fiware-miwi>> > <https://lists.fi-ware.eu/____listinfo/fiware-miwi > <https://lists.fi-ware.eu/__listinfo/fiware-miwi> > <https://lists.fi-ware.eu/__listinfo/fiware-miwi > <https://lists.fi-ware.eu/listinfo/fiware-miwi>>>> > > > > -- > > > > > ------------------------------________------------------------__--__--__--__------------- > > > Deutsches > Forschungszentrum für > Künstliche > Intelligenz (DFKI) GmbH > Trippstadter Strasse 122, > D-67663 > Kaiserslautern > > Geschäftsführung: > Prof. Dr. Dr. h.c. > mult. Wolfgang > Wahlster (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des > Aufsichtsrats: > Prof. Dr. h.c. Hans A. > Aukes > > Sitz der Gesellschaft: > Kaiserslautern (HRB 2313) > USt-Id.Nr.: DE 148646973, > Steuernummer: > 19/673/0060/3 > > > > ------------------------------________------------------------__--__--__--__--------------- > > > > > > _____________________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>> > > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>>> > > <mailto:Fiware-miwi at lists.fi-______ware.eu > <mailto:Fiware-miwi at lists.fi-____ware.eu> > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu>> > > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>>>> > > <mailto:Fiware-miwi at lists.fi-______ware.eu > <mailto:Fiware-miwi at lists.fi-____ware.eu> > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu>> > > > > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>>>> > https://lists.fi-ware.eu/______listinfo/fiware-miwi > <https://lists.fi-ware.eu/____listinfo/fiware-miwi> > <https://lists.fi-ware.eu/____listinfo/fiware-miwi > <https://lists.fi-ware.eu/__listinfo/fiware-miwi>> > > <https://lists.fi-ware.eu/____listinfo/fiware-miwi > <https://lists.fi-ware.eu/__listinfo/fiware-miwi> > <https://lists.fi-ware.eu/__listinfo/fiware-miwi > <https://lists.fi-ware.eu/listinfo/fiware-miwi>>> > > > > > -- > > > > ------------------------------______--------------------------__--__--__------------- > Deutsches Forschungszentrum für > Künstliche > Intelligenz (DFKI) GmbH > Trippstadter Strasse 122, D-67663 > Kaiserslautern > > Geschäftsführung: > Prof. Dr. Dr. h.c. mult. > Wolfgang Wahlster > (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > > Sitz der Gesellschaft: > Kaiserslautern (HRB > 2313) > USt-Id.Nr.: DE 148646973, > Steuernummer: > 19/673/0060/3 > > > ------------------------------______--------------------------__--__--__--------------- > <slusallek.vcf> > > > > > > -- > > > > ------------------------------______--------------------------__--__--__------------- > Deutsches Forschungszentrum für Künstliche > Intelligenz > (DFKI) GmbH > Trippstadter Strasse 122, D-67663 > Kaiserslautern > > Geschäftsführung: > Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster > (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > > Sitz der Gesellschaft: Kaiserslautern (HRB > 2313) > USt-Id.Nr.: DE 148646973, Steuernummer: > 19/673/0060/3 > > > ------------------------------______--------------------------__--__--__--------------- > <slusallek.vcf> > > > > > > > -- > > > > ------------------------------______--------------------------__--__--__------------- > Deutsches Forschungszentrum für Künstliche Intelligenz > (DFKI) GmbH > Trippstadter Strasse 122, D-67663 Kaiserslautern > > Geschäftsführung: > Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster > (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > > Sitz der Gesellschaft: Kaiserslautern (HRB 2313) > USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 > > > ------------------------------______--------------------------__--__--__--------------- > > ___________________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu <mailto:Fiware-miwi at lists.fi-ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>> > <mailto:Fiware-miwi at lists.fi-____ware.eu > <mailto:Fiware-miwi at lists.fi-__ware.eu> > <mailto:Fiware-miwi at lists.fi-__ware.eu > <mailto:Fiware-miwi at lists.fi-ware.eu>>> > https://lists.fi-ware.eu/____listinfo/fiware-miwi > <https://lists.fi-ware.eu/__listinfo/fiware-miwi> > <https://lists.fi-ware.eu/__listinfo/fiware-miwi > <https://lists.fi-ware.eu/listinfo/fiware-miwi>> > > > > > -- > > > ------------------------------____----------------------------__--__------------- > Deutsches Forschungszentrum für Künstliche Intelligenz > (DFKI) GmbH > Trippstadter Strasse 122, D-67663 Kaiserslautern > > Geschäftsführung: > Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > > Sitz der Gesellschaft: Kaiserslautern (HRB 2313) > USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 > > ------------------------------____----------------------------__--__--------------- > > > > > -- > > ------------------------------__------------------------------__------------- > Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH > Trippstadter Strasse 122, D-67663 Kaiserslautern > > Geschäftsführung: > Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > > Sitz der Gesellschaft: Kaiserslautern (HRB 2313) > USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 > ------------------------------__------------------------------__--------------- > > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: slusallek.vcf Type: text/x-vcard Size: 456 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131025/2ed10b76/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy