Should we only have one application domain or two? I think one, but let me have your opinion as well.
Also, let me start the discussion on the feedback we received. Volunteer effort to structure this into topics will be more than welcome.
>Overal impression: - proposal is very relevant to objective 1.2, he seemed to like EUD
Great - we did get the correct signals then.
> - should be clearly on service composition in contrast to well established concepts from component composition
The comment on standards and WSDL++ below for me indicates that this is not suggesting to forget about the ADL and extending the SOA paradigm, but to not to use the word "components" when we mean services ;-)
> - clarify state of the art in domains of component composition and EUD, make clear not to reinvent the wheel
EUD state of art is not a problem, would Siegen happen to have done a review on component composition for that component scripting work described in the CACM paper by Morch and Wolf?
> - be careful about standards, clearly define whether to replace or extend standards, make clear in what respect standards (service descitpion languages) are insufficient and how extension should look like
That is quite clear, I take an action on that, perhaps together with FabioCasati's people. Volkmar could you please provide me with a write-up from group collaboration perspective?
> - section "formal mechanism" seemed to be confusing, how "formal" mechanisms make sense for end users, he understood my clarification, proposal should be clear here
It would make sense to divide "user-facing domain" from "technical domain" (under the bonnet) in terms of structuring of discourse.
- make more clear how DODE would look like, what aspects of domains would be embodied
We should be able to pick a couple of examples - kitchen design of Colorado would be the obvious one.
- explain production process scenario in terms of production process
We can do one of the following:
(b) monitor and control
(d) combinations of these - design by simulation, online simulation to determine best control actions
It would depend on the industrial partner. Currently waiting for this to be finalised by Profactor. But we should also have them on the discussion, hence my wiki suggestion.
> - make clear what the expressiveness of visual language would be, would it be comparable to BPEL?
Depends on the domain I guess.
> - make clear what is specific for service composition in DODE
Wiring processors (reactors, condensors, evaporators, etc) stages together for the purposes (a) to (d) above. Each service handles one processor, we compose them together in a complete process.
> - make clear who the target user would be; a process engineer as domain expert?
> - make clear what added value would be for user
Well they already have such tools, but I would guess they are not integrated with costing nor inventory control nor any other ERP module, also the components we specify in the DODE will be procured on service marketplaces (you always have the most up-to-date and cheapest component, etc.)
>- make clear how objectives are achievable
>- show that you already have concrete ideas
We have to build on existing tools (say the meta-case tool of BOC who are behind ADONIS), and explain we are building upon existing tools (scripting components together, etc.).
>-given the difference between EUD an UI design, one still may ask: how will it show up in UIs?
very nicely indeed , since we can also do usability design and evaluation in addition to the EUD bit.
>-add references to specific ADLs
Action on me. Not a problem.
> - composition should be derived from project content and objectives and expertise brought by partners
> - impotrance of partners to project should be explained
We should have a table cross-linking scientific, technical, business objectives and partner skills. Perhaps we ask each partner to tick the boxes when they fill their page.
> - no general recommendation whether there should be more than one bigger industiral partners
As long as we can argue impact with SAP only, that should be OK.
> - no general recommendation whether there should be a substantial number of application partners even thought the project is focues on end users
> - with SAP as partner he would believe that user requirements are known also without explicit application partners
Profactor also have substantial experience with manufacturing, but who are we to observe doing EUD? SAP developers? ;-)
- do not create the impression that the project is too vague and fundamental requirements have to be defined initially
> I have not asked him explicitly about his opinion on adding a second application domain (such as domotics), since I was expecting a reiteraton of what he said before, i.e. basically the need for a coherent story, addessing a well defined user type
I guess we can add domotics if our process engineering efforts don't bring any results quickly.