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>> 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>>> 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>>>> 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>>), > > 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@>__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>>>: > > 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>>> > 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>>> > 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>>> > 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>> > 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 --------------------------------------------------------------------------- -------------- 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/9f104484/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy