Proposal from telecon

["Barry Norton" <b.j.norton@open.ac.uk>]

My proposal is that we carry through the change suggested at the OASIS
Symposium and develop the ‘Reference Model’ document separately from the
‘Architecture and Information Model’ document, renaming the latter to
‘Reference Architecture’.
 
Concretely, the ‘Reference Model’ will ‘cherry-pick’ from the WSMO
meta-model, aligning the required concepts with the SOA-RM.  Each concept
will be explained through comparison with all the major SWS meta-models, not
just WSMO (though of course, many only appear in WSMO, e.g. goal).  The body
of the ‘Reference Model’ document will use UML Class Diagrams to illustrate
the meta-model.  One appendix will then show these diagrams illustrate the
formal definitions, which we choose to make in WSML.  We note that any
ontology language could have been used at this level, and that our
definitions are a user ontology, distinct from the direct representation of
WSMO in WSML (i.e. _not_ under ‘http://www.wsmo.org/wsml/wsml-syntax#’, the
SEE ontology will be in a different namespace… any suggestions? probably
shouldn’t be under OASIS or WSMO domains – do we need a new one
registering?) 
 
The ‘Reference Architecture’ document will then, as agreed, define the
components as WSML goals (which justifies using WSML over OWL for our
definitions) where the state signatures can refer to concepts in the SEE
Reference Model, rather than the WSML types currently used (e.g. see#goal,
rather than wsml #goal).  As above, WSML will be used in the appendix and
the body will be UML.  Specifically, Class Diagrams will be used to define
the communications, which are WSML ontologies mapped to Class Diagrams as in
the ‘Reference Model’; Activity Diagrams will be used to define the
behavioural parts of the choreographies.  The ‘Reference Architecture’
document will have an appendix explaining the Activity Diagrams and their
relationship to WSML, followed by the WSML definitions.

Finally, the ‘Execution Scenarios’ document will show ‘entry point’ services
to SEE, such as goal-oriented execution, as WSML web services defined as
orchestrations of goals.  At the basic level, they will be compositions of
goals from the ‘Reference Architecture’, but we also allow ourselves
recursive definition so that a goal such as ‘service execution’ can be met
by two (or more) services which are themselves defined in the ‘Execution
Scenarios’ document, as different orchestrations of the architectural
components (to allow both the WSMX and IRS way of doing things) with
different preconditions.  Again, the body of the document will use UML2
Activity Diagrams, and the appendix will represent this in WSML.

Barry