Hi Toni, Great example! WebComponents are meant to allow you to do exactly this on the HTML-5 side and we should be targeting them also in 2D-UI objective. It would be great to port this to the XML3D side to show how we can (hopefully) nice model that also in the Web context. I would love to see and fix any issues we may encounter along this way. This would be a great collaboration and would nicely show the power of our GEs! I very much like the idea of using the mousewheel for opening the door in an analog way. It could even be coupled to a physics engine modifying the mapping based on the mass of the door (or such). Regarding AnyDSL, the JS side would define the "Door" data structure and connect to the corresponding "Door service" on the server side. In our C/C++ implementation, we would then see the native data structures in realXtend and map the JS data structure to the C/C++ data structure and generate optimal code to implement that mapping and the encoding for the communication protocal chosen (REST or binary or so). Currently we assume a 1:1 mapping of the data structures but more complex mappings are possible in a later stage. One thing that is high on my list are optional data elements, that must not always be transmitted for increasing performance and minimizing bandwidth. BTW, in our AI related work, the closed/locked state is exposed as sematic state that is fed into our semantic reasoner and planner in order for an agent to decide what action to do. the agents observes the XML3D scene, feeds this into its believe state, and then decides on the best action to perform to reach his goal(s). The actions are just Web services (maybe implemented within the same Web/JS scene, so not necessarily going to the network). This offers a lot of flexibility but can be costly to compute if you are not careful. Stripped down more reactive, rule-based modes are also possible, of course, and we use both depending on how "intelligent" an agent needs to be. The reasoner and planner are implemented as external Web services. Best, Philipp Am 25.10.2013 09:56, schrieb Toni Alatalo: > On 25 Oct 2013, at 10:05, Tomi Sarni <tomi.sarni at cyberlightning.com > <mailto:tomi.sarni at cyberlightning.com>> wrote: >> 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. > > Having arbitrary custom state is exactly what the entity system in > realXtend is for, and applying the mapping between reX EC model & xml3d > we have now, it would be how we use the xml3d format as well. The ‘x’ in > xml is for ‘extensible’ (and we can nowadays read the X in reX the same > way, though it originally refers to extending reality, not extensible > virtual worlds :) > > The first script + custom component test&demo I made with Naali/Tundra > was a Door. It was implemented by defining a Door component like this: > > Door: > bool: opened > bool: locked > > The functionality was implemented with a script that listened > clicks/touches on the object. If it was closed, but was not opened, it > opened upon touch. If it was already open, it was always closed. If it > was closed by locked, it did not do anything. It could be > locked/unlocked with a GUI button. When hovering with the mouse cursor > over the door the cursor type depended on the state: different icon was > used based on whether it was closed-unlocked, closed-locked or opened > (to communicate the action that would happen in advance to the user). > The demo scene + code for that is in the tundra 1 branch, > https://github.com/realXtend/naali/blob/tundra/bin/scenes/Door/door.coffee > .. the port to tundra2 was not completed (yet?) so it’s not in current — > would still be a nice demo of using custom data + scripting I think, > feel free to port it anyone! The model is a nicely modelled & rigged > accordion door (haitariovi) even which animates. Next planned step was > to allow use of mouse wheel to slide (animate) the door partially to > test streaming sync and not just boolean toggles, I think I tested > somehow a little too then. > > So in the human friendly xml format (i.e. xml3d) that example would look > like this: > > <group name=“SlidingDoor"> > <mesh src=“slidingdoor.mesh” /> > <door opened=“false" locked=“false” /> > </group> > > Whereas the same as TXML, the relevant parts copy-pasted from > https://github.com/realXtend/naali/blob/tundra/bin/scenes/Door/door.txml > is: (note that this is tundra1 txml so a bit different from current 2.x > series!) > > <entity id="1"> > <component type="EC_Mesh" sync="1"> > <attribute value="slidingdoor.mesh" name="Mesh ref"/> > <attribute value="slidingdoor.skeleton" name="Skeleton ref"/> > <attribute value="lasi_vaalvihrea.material" name="Mesh materials"/> > </component> > <component type="EC_Name" sync="1"> > <attribute value="SlidingDoor" name="name"/> > </component> > <component type="EC_Script" sync="1" name="doorlogic"> > <attribute value="js" name="Type"/> > <attribute value="true" name="Run on load"/> > <attribute value="door.js" name="Script ref"/> > </component> > <component type="EC_DynamicComponent" sync="1" name="door"> > <attribute value="true" type="bool" name="opened"/> > <attribute value="false" type="bool" name="locked"/> > </component> > </entity> > > You can see how it uses DynamicComponent -- that’s due to the weakness > of the JS API in Tundra currently which was discussed in an earlier > thread here on MIWI: ideally it would say (EC_)Door in that TXML. > > In the xml3d example it is assumed that we have a way to register custom > handlers for component types without separate script-references. That’s > how I originally implemented the system in Tundra 0.x times too and how > the original door implementation worked (the component registry and > sandboxed JS Api exposing was first implemented in Python which was made > optional later, and the later made EC_Script mechanism made the > component type handler registry quite redundant - it was nicer though to > only need to add one component to make an object a Door for example .. > currently I think it goes ok so that the handler script creates the data > component it needs so that users don’t need to add two manually). In > current Tundra you’d get the EC_Door working just like that in C++ > implementing the IComponent interface. > > ~Toni > > >> 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 >> ------------------------------__------------------------------__--------------- >> >> > > > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > 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 --------------------------------------------------------------------------- -------------- 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/1ff8b312/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy