Hi,
Sounds great!!
Again let me know if you want to discuss a more general and abstract
handling of events (at least for 3D stuff).
Best,
Philipp
Am 04.11.2013 08:02, schrieb Antti Kokko:
> Hello,
>
> I have been doing research and testing with Polymer and input devices.
> Regarding Polymer it really feels the way to go with the 2D-UI GE. I
> read somewhere that the AngularJS will be moving towards Shadow DOM as
> well and will include Polymer later on.
>
> With Polymer I have been doing a test implementation for chat app we
> have in WebRocket. Implementing the actual UI component with Polymer was
> pretty trivial and very nice to work with from a web designer point of
> view. As end result there is clear readable output including 2 html
> files and one css file. All functions have been encapsulated to the
> component itself. Therefore it becomes re-usable although in this case
> the component needs data binding and event hooking corresponding to the
> backend used. But in general when the backend is solid and decided
> implementing the web components will be nice work. Polymer already gives
> a huge set of components ready to use and work with. For this case I
> used polymer-collapse to slide up/down div elements I created. For this
> I needed only to import the corresponding polymer-collapse html file and
> hook it to my div element. Very easy and convenient. Right now I try to
> tackle the require js issues for WebRocket related to Polymer.
>
> For input devices I have been researching and testing touch JS libs and
> Gamepad API. For touch I tested couple of libraries and all of them
> worked well. As end result I chose jquery plugin and tested it against
> iPhone and iPad. Worked pretty well and I managed to get taps for 1-4
> fingers, sliding and pinching to work. Shake and rotate didn´t work for
> some reason but I didn´t go deeper with that issue.
>
> For Gamepad I used Gamepad API
> [https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html]. Got it
> working well with Chrome. With Firefox it didn´t work even with Nightly
> build, don´t know the reason. Anyway the implementation is already
> tested against web rocket and Jonne did a nice test with the avatar app
> we have. Gamepad works like a charm. For tests we used XBOX 360
> controller and Playstation controller. With Windows just plugging the
> device to USB port and pushing some button is everything needed. Both
> gamepads worked right away.
>
> The next thing with input is to test/research is Kinect.
>
> Thanks,
>
> - Antti
>
>
> On Sun, Nov 3, 2013 at 10:24 AM, Philipp Slusallek
> <Philipp.Slusallek at dfki.de <mailto:Philipp.Slusallek at dfki.de>> wrote:
>
> Hi,
>
> Sounds really good. I would suggest that we start defining the
> WebComponent components and their interfaces soon (of course, based
> on what you already use, but have a quick process to discuss if
> there could be improvements) and then go from there. In parallel we
> can check that XML3D works well with WebComponents and Polmer.
>
> I believe we have talked about that a bit already but I am not sure
> we have a specification for the WebComponents yet. Torsten, can you
> work with whoever feels responsible on the Finish side to come up
> with a common specification (somewhere on the private pages for now)?
>
> Sounds like we are all working in the same direction -- which is
> great! I can't wait to see the first avatars walking to Oulu city
> (or some other place) in any Web browser :-).
>
>
> Best,
>
> Philipp
>
> Am 03.11.2013 08:23, schrieb Toni Alatalo:
>
> Again a brief note about a single point:
>
> On 03 Nov 2013, at 09:12, 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:
>
> Also there might be convenient components that would make 3D app
> programming with XML3D and WebComponents much easier. So for
> instance
> having the XML3D-based components automatically define the
> set of
> variable that need to be synchronized, registering them with the
> networking module (if available), and making sure this all
> gets done
> in the background would be excellent. Also providing an 3D
> avatar
> WebComponent with embedded animations and such would be
> ideal. It
> would be excellent if we could provide to Web developers a
> whole set
> of predefined and modular WebComponents that they could just
> use to
> create 3D worlds with behaviour.
>
>
> This is what realXtend has been doing for several years — just
> outside
> the Web — and plan is to continue doing the same on the Web as
> well :)
>
> That’s how it works in the native Tundra, and plan for this
> fi-ware work
> to produce the web client (which also works standalone, like the
> native
> one does too) is to implement the same. That’s also how it works in
> Chiru-WebClient and WebRocket, i.e. the pre-existing WebTundra’s.
>
> ~Toni
>
> The one really big issue where I still see a lot of work on
> finding
> new solutions (not just implementation but real conceptual
> work) is
> dealing with the hugely varying set of input devices. One
> person has
> mouse and keyboard, the next has only a multi-touch surface,
> the next
> is using a Kinect, while yet another other is using a Wii
> Remote, etc.
> A single Web app will have to work with all of those situations
> simultaneously (on different devices, though). Letting Web
> application
> and their developers handle this in their apps will simply
> not work
> and be frustrating for developer and users.
>
> We have started to work on a concept for this but this has
> not gone
> very far yet. The coarse idea is that applications use virtual
> interaction elements to say what kind of input (metaphor)
> they are
> expected (e.g. selection of an object, moving an object).
> These are
> modules that can be configured and instantiated. They can
> also be
> nested within/on top each other (like non-visible dialog boxes)
> dynamically to have a hierarchical finite state machine of
> interactions.
>
> These interaction elements would consist of the interaction
> logic as
> well as (optionally) some interaction gadgets that visually
> represent
> the possible interactions (like handles to move and rotate
> an object).
> The key thing is that these interaction elements would be
> independent
> of the application, anyone can use them, and we could
> develop a whole
> library of them to cover the wide range of input metaphors that
> applications use (but applications can extend them with
> their own if
> needed).
>
> There are two extensions to this approach: (i) instead of
> having a
> single interaction element for each interaction metaphor we
> could have
> interfaces for them and develop entire user interface
> libraries that
> each have a different look and feel but still implement the
> same basic
> interaction metaphor. (ii) One could also design them such
> that users
> can change the mapping of the devices used for certain
> actions. Think
> of it as a reconfigurable gamer mouse, where the user can assign
> different action to certain buttons, gestures, or such. So a
> user can
> say, I will use the mouse to select objects but move them
> with the
> cursor keys (for a stupid simple example). These would be
> optional
> extensions for later, though.
>
> It would be great to work on those aspects together if this
> would be
> interesting to anyone of you. You probably have quite some
> experience
> in terms of good UI for 3D games/apps. Identifying,
> generalizing, and
> implementing them as a reusable set of components would a
> great step
> forward for 3D apps on the Web (or elsewhere). This would
> make great
> papers for conferences as well!
>
> If you want to go that way, we should probably set up a special
> session for discussing this in more detail.
>
>
> Best,
>
> Philipp
>
> Am 02.11.2013 17:35, schrieb Jonne Nauha:
>
> Yeah WebComponents are nice. I've already implemented
> quick tests for
> Tundras Entity and IComponent (common interface for all
> components,
> WebComponents has inheritance so it plays nicely into
> this) like 3-4
> months ago in our WebRocket web client. At that point I
> left it alone, I
> wanted to have my JS code that implements the component
> in a .js file
> not inside a .html polymer template. Currently I'm using
> requirejs for
> the whole repo as the amount of code and dependency
> tracking started to
> get out of hand, so I wanted a modular system where I
> can tell the
> system what each module needs as a dependency. This has
> been great but
> will make writing comp implementations in a WebComponent
> html template a
> bit trickier as it would expect everything to in global
> scope,
> requierejs effectively removes everything from global scope.
>
> I have also a simple DOM integration plugin for
> WebRocket. If you want
> to turn it on (configurable when you construct the
> client instance) it
> will mirror the whole scene/entity/component/__attribute
> chain in to the
> DOM as my own
> <scene><entity><component><__attribute/>...</component>...<__/entity>...</scene>
> nodes. This would be trivial to change to create XML3D
> nodes, but I cant
> test that out before everything on the asset side that
> has been
> discussed are complete. Because nothing would simply
> render if I wont
> provide the Ogre asset loaders for XML3D and it knowing
> how to used DDS
> textures. What I would prefer even more is to just pass
> you the geometry
> as data, because I have my own fully working AssetAPI to
> fetch the
> assets, and I have my own loaders for each asset type I
> support. I would
> kind of be duplicate work to re-implement then as XML3D
> loaders, when I
> alreayd have the ready typed gl arrays to give to you
> right now.
>
> For my current DOM "mirroring" plugin, if you manipulate
> the attributes
> in the DOM they wont sync up back to the in mem
> JavaScript attributes.
> So currently its read only. I haven't really had the
> need to implement
> the sync the other way as we are perfectly happy living
> in JS land and
> using the WebRocket SDK API to write our application
> logic. The
> declarative side is less important for Meshmoon
> WebRocket as the scenes
> are always coming from our Tundra based servers and not
> declared on the
> html page itself. For FIWARE the declarative and DOM
> side is more
> important and more in focus of course so I understand
> the direction of
> the talks and why XML3D is an valuable asset.
>
> Instantiating Scene, Entity and each of the Component
> implementation
> from a WebComponent template would solve this problem,
> as its designed
> to encapsulate the JS implementation and it has a great
> way to get
> callbacks when any attribute in the DOM node is
> manipulated. It can also
> expose DOM events and fire them, not to mention normal
> functions eg.
> $("<placeable>", entityNode).setPosition(10,20,__30); so
> you dont have to
> use the raw DOM api to set string attributes by random.
> These functions
> would have type checking and not let you put carbage
> into the
> attributes. I believe the attribute changed handler can
> also effectively
> abort the change if you are trying to put a boolean to a
> Vector3
> attribute. This all is great and would just require us
> WebRocket devs to
> port our current EC implementations to WebComponent
> templates.
>
> But here is where I get confused. So you would be fine by us
> implementing Tundra components as WebComponent templates
> (as said this
> would be fairly trivial). How would XML3D then play into
> this situation?
> Would it now monitor our DOM elements instead of the
> ones you specify
> (afaik eg. <group> <mesh>)? Can you open up this a bit?
>
> *UI and WebComponents*
> *
> *
> WebComponents are also being looked at in our 2D-UI GE,
> but to be frank
> there is very little to do there. The system is
> incredibly simple to
> use. You include polymer.js to you page, add <link> tags
> to your Polymer
> style .html templates, then you just use the tags
> declared in them on
> the markup or you create the DOM nodes during runtime
> from JS with your
> preferred method. I'm having a bit of hard time figuring
> out what we
> should focus on in the 2D part for WebComponents. I mean
> they are there
> and you can use them, you don't need any kind of special
> APIs or
> supporting code from our side for them to work. Only
> thing I can think
> of is implementing some widgets and maybe 3D related
> templates for
> anyone when they use WebTundra.
>
> Best regards,
> Jonne Nauha
> Meshmoon developer at Adminotech Ltd.
> www.meshmoon.com <http://www.meshmoon.com>
> <http://www.meshmoon.com/><htt__p://www.meshmoon.com
> <http://www.meshmoon.com>
> <http://www.meshmoon.com/>>
>
>
>
> On Sat, Nov 2, 2013 at 1:21 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 at dfki.de
> <mailto:Philipp.Slusallek at dfki.de>>>
>
> wrote:
>
> Hi Toni, all,
>
> I have now looked at video on the main Polymer page
> (http://www.polymer-project.____org/
> <http://www.polymer-project.__org/
> <http://www.polymer-project.org/>>), which is actually
> very nicely
> done. They make a very good point why its
> advantageous to put things
> in the DOM compared to pure JS applications (or even
> Angular, which
> already uses the DOM). They highlight that with
> WebComponents
> (Polymer is a polyfill implementation of them) this
> becomes now even
> easier and creates an object-oriented aspect for HTML.
>
> BTW, this aspect is exactly what we were aiming at
> when we suggested
> the use of WebComponents for the 2D-UI Epic in the
> objectives of the
> FI-WARE Open Call and I think we should push even
> more in this
> direction, similar to what I wrote in response to
> Jonne's email
> earlier.
>
> Regarding the mapping: We already have the mapping
> of 3D to the DOM
> (XML3D) as well as many modules that build on top of
> that mapping
> (Xflow with animation, image processing, and AR;
> portable materials,
> etc.). I see no reason why we should throw this out
> just because
> there is a slightly different way of doing it.
>
> I would even speculate that if we would try to offer
> similar
> functionality that at the end we would end up with
> something that
> would pretty much resemble XML3D, maybe with a
> slightly different
> syntax. There are usually not many way to do the
> same thing in a
> good way.
>
> What I would support 100%, however, is that we try
> to use
> Web*Components* to implement the *ECA components*
> (and possibly
> entities). Essentially for the same reasons
> explained in the video.
> That makes a lot of sense in the Web context and is
> fully compatible
> with the DOM and all the DOM-based frameworks that
> can then be used
> as well on this data.
>
> I have been saying for a long time that we have had
> libraries in
> C/C++. Just porting them to JS to run in the Web
> does not give us
> any advantages at all (likely only disadvantages
> like performance
> and an inferior language). Its only if we embrace
> the key elements
> of the Web -- and the runtime DOM arguably is the
> core of it all --
> that we can tap into all the benefits of the Web.
>
> And THE key advantage of the DOM is that you get
> *way more* than the
> sum of the pieces when putting things together.
> Instead, of making
> sure that one library can talk to all the others
> (which gets you
> into an N^2 complexity problem), each component only
> needs to work
> with the DOM (constant effort per component and you
> have to deal
> with one data structure anyway, so its essentially
> no overhead
> anyway). Then, you get the benefit from all other
> components
> *automatically and completely for free* (jquery and
> all the other
> tools "just work" also with XML3D, and we should be
> able to use
> XML3D within Polymer also).
>
> Note, that none of the Web technologies discussed here
> (WebComponents, Polymer, Angular, etc.) would work
> at all if they
> would not use the DOM at their core. Angular for
> example depends on
> the DOM and just allows a nicer binding of custom
> functionality
> (controller implemented in JS) to the DOM.
>
> This all applies exactly the same way also to 3D
> data -- at least
> logically. However, on the implementation side 3D is
> special because
> you have to take care of large data structures,
> typed arrays, and so
> on. This is what the main work in XML3D was all
> about. Why should
> someone invest all the effort to do it again for
> likely very similar
> results in the end?
>
> We can talk about using three.js as a renderer,
> though, but I would
> not touch the 3D DOM binding and data model that we
> already have in
> XML3D (unless someone comes with very good reasons
> to do so).
>
>
> Best,
>
> Philipp
>
>
> Am 02.11.2013 09:27, schrieb Toni Alatalo:
>
> On 02 Nov 2013, at 09:09, 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 at dfki.de
> <mailto:Philipp.Slusallek at dfki.de>>>
>
> wrote:
>
> Nice stuff. from my perspective there are
> two ways to look
> at this work: One is to provide high level
> UI elements on
> top of a three.js implementation and the
> other is the start
> of creating a declarative layer on top of
> the three.js
> renderer. This seems more along the first
> line but both
> should be similarly interesting to us.
>
>
> Indeed.
>
> It great to see that other people are coming
> up with similar
> ideas now. It would be good to get the
> message about our
> XML3D design and implementation to these
> people out there.
> That way we could improve what we already
> have instead of
> reinventing the wheel.
>
>
> That was my immediate first thought as well: it
> seemed like
> people have started to reinvent declarative 3d
> for the web from
> scratch. That’s why I asked whether they knew
> about the existing
> work — I understood that this Josh Galvin person
> (don’t know him
> from before) who made the Spinner demo, did (am
> not sure).
>
> Thanks for the views and pointers, I’ll keep an
> eye open for
> talks about this (actually just joined the
> #three.js irc channel
> on freenode yesterday, haven’t been involved in
> their community
> before really — Tapani from us has been hanging
> out there
> though). They seem to communicate most in the
> github issue
> tracker and pull requests (which I think is a
> great way).
>
> I also did not find an e-mail address to the
> polymer-threejs
> person, butkaosat.net <http://butkaosat.net>
> <http://kaosat.net/><http://__kaosat.net <http://kaosat.net>
> <http://kaosat.net/>> is his personal site
>
> and apparently he made the original announcement
> of the
> declarative three.js thing in August in Google+
> so I figure e.g.
> replying there would be one way to comment:
> https://plus.google.com/____112899217323877236232/posts/____bUW1hrwHcAW
> <https://plus.google.com/__112899217323877236232/posts/__bUW1hrwHcAW>
>
> <https://plus.google.com/__112899217323877236232/posts/__bUW1hrwHcAW <https://plus.google.com/112899217323877236232/posts/bUW1hrwHcAW>>
> ..
> I can do that on Monday.
>
> BTW it seems that this guy is into hardware and
> cad and all
> sorts of things and declarative 3d xml is just a
> side thing for
> fun, perhaps related to his work on some cad
> thing — is not like
> he’d be pursuing a career or a product or
> anything out of it.
>
> It seems like a straightforward mapping of the
> three.js API to
> xml elements: what I struggle to understand now
> is whether
> that’s a good abstraction level and how does it
> correspond to
> xml3d’s vocabulary.
>
> ~Toni
>
> It would be good if you can point people
> also to our papers
> from this year
>
> (http://graphics.cg.uni-____saarland.de/publications/
> <http://graphics.cg.uni-__saarland.de/publications/>
>
> <http://graphics.cg.uni-__saarland.de/publications/
> <http://graphics.cg.uni-saarland.de/publications/>>). They
> explain a lot of the background of why we
> have chose thing
> to work the way they work.
>
> More specifically:
> -- The "xml3d.js" paper explain a lot about
> the design of
> XML3D and its implementation
>
> (https://graphics.cg.uni-____saarland.de/2013/xml3djs-____architecture-of-a-polyfill-____implementation-of-xml3d/ <https://graphics.cg.uni-__saarland.de/2013/xml3djs-__architecture-of-a-polyfill-__implementation-of-xml3d/>
>
> <https://graphics.cg.uni-__saarland.de/2013/xml3djs-__architecture-of-a-polyfill-__implementation-of-xml3d/ <https://graphics.cg.uni-saarland.de/2013/xml3djs-architecture-of-a-polyfill-implementation-of-xml3d/>>).
> -- The "Declarative image processing" paper
> explains all the
> advantages one gets from exposing processing
> elements to the
> DOM instead of implementing them only in
> some JS libraries
>
> (https://graphics.cg.uni-____saarland.de/2013/declarative-____ar-and-image-processing-on-____the-web-with-xflow/ <https://graphics.cg.uni-__saarland.de/2013/declarative-__ar-and-image-processing-on-__the-web-with-xflow/>
>
> <https://graphics.cg.uni-__saarland.de/2013/declarative-__ar-and-image-processing-on-__the-web-with-xflow/ <https://graphics.cg.uni-saarland.de/2013/declarative-ar-and-image-processing-on-the-web-with-xflow/>>).
> -- And the 2012 paper on "XFlow" shows this
> usage for
> animation
>
> (https://graphics.cg.uni-____saarland.de/2012/xflow-____declarative-data-processing-____for-the-web/ <https://graphics.cg.uni-__saarland.de/2012/xflow-__declarative-data-processing-__for-the-web/>
>
> <https://graphics.cg.uni-__saarland.de/2012/xflow-__declarative-data-processing-__for-the-web/ <https://graphics.cg.uni-saarland.de/2012/xflow-declarative-data-processing-for-the-web/>>)
>
> Getting into a constructive discussion with
> some of these
> three.js people would be a good thing. I
> tried to find an
> email address for the polymer-threejs person
> but could not
> find any. Feel free to farward this email to
> him (and maybe
> others). I would love to get their feedback
> and engage in
> discussions.
>
>
> Best,
>
> Philipp
>
> Am 02.11.2013 00:38, schrieb Toni Alatalo:
>
> Apparently some three.js user/dev has
> gotten inspired by
> WebComponents &
> the Polymeer and written
> https://github.com/kaosat-dev/____polymer-threejs
> <https://github.com/kaosat-dev/__polymer-threejs>
>
> <https://github.com/kaosat-__dev/polymer-threejs
> <https://github.com/kaosat-dev/polymer-threejs>> :)
>
> Now another guy has continued with
> https://github.com/JoshGalvin/____three-polymer
> <https://github.com/JoshGalvin/__three-polymer>
>
> <https://github.com/__JoshGalvin/three-polymer
> <https://github.com/JoshGalvin/three-polymer>> — there’s
> a demo of custom
> element (‘spinner’), similar to the Door
> case discussed
> here earlier.
>
> Had a brief chat with him, will return
> to this later but
> was fun to see
> the minimal webgl web component example
> there as that
> has been in our
> agenda.
>
> ~Toni
>
> 01:01 *<* galv*>*
> https://github.com/JoshGalvin/____three-polymer
> <https://github.com/JoshGalvin/__three-polymer>
>
> <https://github.com/__JoshGalvin/three-polymer
> <https://github.com/JoshGalvin/three-polymer>> added
> support for more basic geometry types
> 01:02 *<* galv*>* Going to do materials next
> 01:25 *<* *antont**>* galv: hee - are
> you aware of these
> btw?
> http://www.w3.org/community/____declarative3d/
> <http://www.w3.org/community/__declarative3d/>
>
> <http://www.w3.org/community/__declarative3d/
> <http://www.w3.org/community/declarative3d/>> , e.g.
> https://github.com/xml3d/____xml3d.js
> <https://github.com/xml3d/__xml3d.js>
> <https://github.com/xml3d/__xml3d.js
> <https://github.com/xml3d/xml3d.js>>
> 01:27 *<* galv*>* yeah, different level
> of abstraction
> 01:27 *<* *antont**>* perhaps
> 01:28 *<* galv*>* I expect people to
> wrap up their game
> objects
> 01:28 *<* galv*>* aka "spinner"
> 01:28 *<* galv*>* (index.html)
> 01:29 *<* *antont**>* we've been also
> planning to enable
> saying things
> like <door> if that's what you mean
> 01:30 *<* *antont**>* right, seems like
> the same idea
> 01:31 *<* *antont**>* very cool to see,
> gotta check the
> codes etc later
> .. but sleep now, laters
>
>
>
>
> ___________________________________________________
> 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>>
> 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
>
> ------------------------------____----------------------------__--__---------------
>
> _________________________________________________
> 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>>
> 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
> ------------------------------__------------------------------__---------------
>
> _______________________________________________
> Fiware-miwi mailing list
> Fiware-miwi at lists.fi-ware.eu <mailto: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: 441 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131104/45a2bf97/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy