You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@taverna.apache.org by st...@apache.org on 2018/06/29 09:01:49 UTC
incubator-taverna-plugin-component git commit: GitHub uses README.md
instead of index.md
Repository: incubator-taverna-plugin-component
Updated Branches:
refs/heads/master bb94976c9 -> aaa2befc1
GitHub uses README.md instead of index.md
Project: http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/commit/aaa2befc
Tree: http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/tree/aaa2befc
Diff: http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/diff/aaa2befc
Branch: refs/heads/master
Commit: aaa2befc1721e644312ef7adfbd52ed56c6b3862
Parents: bb94976
Author: Stian Soiland-Reyes <st...@apache.org>
Authored: Fri Jun 29 10:01:37 2018 +0100
Committer: Stian Soiland-Reyes <st...@apache.org>
Committed: Fri Jun 29 10:01:37 2018 +0100
----------------------------------------------------------------------
README.md | 2 +-
doc/README.md | 162 +++++++++++++++++++++++++++++++++++++++++++++++++++++
doc/index.md | 162 -----------------------------------------------------
3 files changed, 163 insertions(+), 163 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/blob/aaa2befc/README.md
----------------------------------------------------------------------
diff --git a/README.md b/README.md
index bbee7db..d0849b3 100644
--- a/README.md
+++ b/README.md
@@ -21,7 +21,7 @@ Plugins for
[Apache Taverna](http://taverna.incubator.apache.org/) for
supporting components.
-[Taverna Workflow Components](doc/index.md) are a system for creating shareable,
+[Taverna Workflow Components](doc/) are a system for creating shareable,
reusable, encapsulated sub-workflows that perform clearly defined tasks while
abstracting the details of how those tasks are performed.
http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/blob/aaa2befc/doc/README.md
----------------------------------------------------------------------
diff --git a/doc/README.md b/doc/README.md
new file mode 100644
index 0000000..92d6247
--- /dev/null
+++ b/doc/README.md
@@ -0,0 +1,162 @@
+# Workflow Components
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+
+## Overview
+Taverna Workflow Components are a system for creating shareable, reusable,
+ encapsulated sub-workflows that perform clearly defined tasks while abstracting
+ the details of how those tasks are performed.
+They are an integrated feature of Taverna since Workbench 2.5.0 and Server 2.5.4.
+
+Taverna's system of service components was developed as part of the BioVeL and SCAPE projects. They consist of tools for the creation, management and use of workflow components,
+ along with a repository for the storage and sharing of those components.
+Workflow components within a given component family will work together cleanly,
+ for example, by adhering to a tidy type system and being well described.
+
+## Requirements
+
+A set of minimal functional requirements for service component management has been developed. These requirements are
+ based upon previous component-related work carried out as part of the e-Lico project as well as an examination of the needs of BioVeL and SCAPE.
+
+The requirements include:
+
+ - The ability to create components
+ - The specification of the characteristics that are necessary for a set of components to
+ ‘play’ together – called a ‘component profile’
+ - Creating a component so it complies with a given profile
+ - Checking that a component complies with a given profile
+ - Publishing a component
+ - Discovering a component
+ - Including a component in a workflow
+ - Executing the component within a workflow run
+
+<img class="aligncenter" title="The Model of Components" src="img/registry.png" alt=""
+ width="433" height="251" />
+
+## Workflows
+### Example workflow with components
+
+This is an example workflow that includes components, with internal ports hidden for simplicity:
+
+<img class="alignnone" title="Componentized Workflow" src="img/component_b_1.png" alt=""
+ width="679" height="294" />
+
+Without components, using the same view, it would instead look like this:
+
+[<img class="aligncenter" title="Un-componentized Workflow" src="img/component_c.png" alt="" width="245" height="526" />](http://www.taverna.org.uk/pages/wp-content/uploads/2013/05/component_c.png)
+
+### Including a component in a workflow
+
+A component can be added into a Taverna workflow in the same way as an ordinary service:
+ by dragging it from the service panel of the workbench into the workflow design view.
+ *Although it may be realized internally as a workflow,
+ a user sees it as a ‘black box’ and cannot (normally) edit the component’s workflow.*
+
+<img class="aligncenter" src="img/arch3.png" alt="" width="500" height="401" />
+
+It is intended that there will be consistency checks to ensure components are only plugged
+ together in a sensible manner, and for the discovery of (and connection to) suitable components
+ based upon existing workflow structure.
+
+### Executing a component in a workflow run
+
+When a component is invoked during a workflow run, the underlying workflow is called with the
+ corresponding data.
+The results of the workflow are used as the output data for the component invocation.
+*The user sees the component invocation as a ‘black box’ and cannot see details of
+ what happens inside.*
+
+>If you publish a workflow containing a component, you *must* make sure the
+ component is publicly readable in a globally-accessible component registry;
+ myExperiment is such a suitable registry.
+
+## Components
+### Component creation
+
+It was decided that the majority of the information necessary for a component will be specified
+ as a Taverna workflow.
+This allows complex internal component functionality and removes the need for extensive new
+ software to design components.
+
+<img class="aligncenter" src="img/arch1.png" alt="" width="340" height="433" />
+
+### Component profile
+
+A specification of the format for the component profile has been agreed.
+The format is in XML and an XML schema (xsd) has been created.
+An example [component profile](http://www.myexperiment.org/files/905/versions/1/download/Characterisation%20Component.xml)
+ is available.
+Components that share a profile will be collected together into component families.
+A [component profile editor](/documentation/components/component-profile-editor)
+ is being developed.
+
+<p style="text-align: center;">
+<img class="aligncenter" src="img/arch2.png" alt="" width="359" height="412" />
+</p>
+
+The SCAPE project has an
+ [extended discussion of component profiles](https://github.com/openpreserve/scape-component-profiles)
+ available.
+
+### Component creation against a profile
+
+In order to conform to a component profile, it can be necessary to make semantic annotations
+ parts of the corresponding workflow.
+For example, the annotation of the type of format in which data is output by a port or
+ a service with the task it performs.
+
+The component profile specifies the ontologies that will be used for the components within the
+ family, the correspondence between object classes within a workflow
+ (input port, service etc.) and the concepts within the ontologies.
+
+### Checking a component against a profile
+
+Although the components will be modified using a chosen profile,
+ it is unlikely that the components can be assured as being ‘correct by construction’.
+For this reason, a separate
+ [component validator](/documentation/components/component-validator)
+ is being implemented.
+The component validator is included within
+ [myExperiment](http://www.myexperiment.org).
+
+### Publishing a component
+
+Since components are realized as ‘extensions’ to Taverna workflows,
+ it was decided that rather than using a separate component repository,
+ the extensive capabilities of myExperiment would be used.
+Thus a component is currently published and shared on myExperiment as (a pack containing)
+ a workflow.
+The components themselves are items within a pack corresponding to the component family.
+
+To facilitate the development of components, a workflow can also be saved to the user’s local
+ machine.
+
+When a user publishes a component either to myExperiment or to their local file system,
+ their service panel is updated to reflect the new component.
+
+### Discovering a component
+
+Since component families are realized as packs on myExperiment
+ (or by analogous structures in the user’s file system),
+ we use the existing Taverna code to talk to the myExperiment REST interface to give users
+ access to families of components.
+Users can then see the discovered families of components via the Taverna Workbench service
+ panel, and the components within those families.
+A component can then be added to a workflow.
http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/blob/aaa2befc/doc/index.md
----------------------------------------------------------------------
diff --git a/doc/index.md b/doc/index.md
deleted file mode 100644
index 92d6247..0000000
--- a/doc/index.md
+++ /dev/null
@@ -1,162 +0,0 @@
-# Workflow Components
-
-<!--
- Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
--->
-
-## Overview
-Taverna Workflow Components are a system for creating shareable, reusable,
- encapsulated sub-workflows that perform clearly defined tasks while abstracting
- the details of how those tasks are performed.
-They are an integrated feature of Taverna since Workbench 2.5.0 and Server 2.5.4.
-
-Taverna's system of service components was developed as part of the BioVeL and SCAPE projects. They consist of tools for the creation, management and use of workflow components,
- along with a repository for the storage and sharing of those components.
-Workflow components within a given component family will work together cleanly,
- for example, by adhering to a tidy type system and being well described.
-
-## Requirements
-
-A set of minimal functional requirements for service component management has been developed. These requirements are
- based upon previous component-related work carried out as part of the e-Lico project as well as an examination of the needs of BioVeL and SCAPE.
-
-The requirements include:
-
- - The ability to create components
- - The specification of the characteristics that are necessary for a set of components to
- ‘play’ together – called a ‘component profile’
- - Creating a component so it complies with a given profile
- - Checking that a component complies with a given profile
- - Publishing a component
- - Discovering a component
- - Including a component in a workflow
- - Executing the component within a workflow run
-
-<img class="aligncenter" title="The Model of Components" src="img/registry.png" alt=""
- width="433" height="251" />
-
-## Workflows
-### Example workflow with components
-
-This is an example workflow that includes components, with internal ports hidden for simplicity:
-
-<img class="alignnone" title="Componentized Workflow" src="img/component_b_1.png" alt=""
- width="679" height="294" />
-
-Without components, using the same view, it would instead look like this:
-
-[<img class="aligncenter" title="Un-componentized Workflow" src="img/component_c.png" alt="" width="245" height="526" />](http://www.taverna.org.uk/pages/wp-content/uploads/2013/05/component_c.png)
-
-### Including a component in a workflow
-
-A component can be added into a Taverna workflow in the same way as an ordinary service:
- by dragging it from the service panel of the workbench into the workflow design view.
- *Although it may be realized internally as a workflow,
- a user sees it as a ‘black box’ and cannot (normally) edit the component’s workflow.*
-
-<img class="aligncenter" src="img/arch3.png" alt="" width="500" height="401" />
-
-It is intended that there will be consistency checks to ensure components are only plugged
- together in a sensible manner, and for the discovery of (and connection to) suitable components
- based upon existing workflow structure.
-
-### Executing a component in a workflow run
-
-When a component is invoked during a workflow run, the underlying workflow is called with the
- corresponding data.
-The results of the workflow are used as the output data for the component invocation.
-*The user sees the component invocation as a ‘black box’ and cannot see details of
- what happens inside.*
-
->If you publish a workflow containing a component, you *must* make sure the
- component is publicly readable in a globally-accessible component registry;
- myExperiment is such a suitable registry.
-
-## Components
-### Component creation
-
-It was decided that the majority of the information necessary for a component will be specified
- as a Taverna workflow.
-This allows complex internal component functionality and removes the need for extensive new
- software to design components.
-
-<img class="aligncenter" src="img/arch1.png" alt="" width="340" height="433" />
-
-### Component profile
-
-A specification of the format for the component profile has been agreed.
-The format is in XML and an XML schema (xsd) has been created.
-An example [component profile](http://www.myexperiment.org/files/905/versions/1/download/Characterisation%20Component.xml)
- is available.
-Components that share a profile will be collected together into component families.
-A [component profile editor](/documentation/components/component-profile-editor)
- is being developed.
-
-<p style="text-align: center;">
-<img class="aligncenter" src="img/arch2.png" alt="" width="359" height="412" />
-</p>
-
-The SCAPE project has an
- [extended discussion of component profiles](https://github.com/openpreserve/scape-component-profiles)
- available.
-
-### Component creation against a profile
-
-In order to conform to a component profile, it can be necessary to make semantic annotations
- parts of the corresponding workflow.
-For example, the annotation of the type of format in which data is output by a port or
- a service with the task it performs.
-
-The component profile specifies the ontologies that will be used for the components within the
- family, the correspondence between object classes within a workflow
- (input port, service etc.) and the concepts within the ontologies.
-
-### Checking a component against a profile
-
-Although the components will be modified using a chosen profile,
- it is unlikely that the components can be assured as being ‘correct by construction’.
-For this reason, a separate
- [component validator](/documentation/components/component-validator)
- is being implemented.
-The component validator is included within
- [myExperiment](http://www.myexperiment.org).
-
-### Publishing a component
-
-Since components are realized as ‘extensions’ to Taverna workflows,
- it was decided that rather than using a separate component repository,
- the extensive capabilities of myExperiment would be used.
-Thus a component is currently published and shared on myExperiment as (a pack containing)
- a workflow.
-The components themselves are items within a pack corresponding to the component family.
-
-To facilitate the development of components, a workflow can also be saved to the user’s local
- machine.
-
-When a user publishes a component either to myExperiment or to their local file system,
- their service panel is updated to reflect the new component.
-
-### Discovering a component
-
-Since component families are realized as packs on myExperiment
- (or by analogous structures in the user’s file system),
- we use the existing Taverna code to talk to the myExperiment REST interface to give users
- access to families of components.
-Users can then see the discovered families of components via the Taverna Workbench service
- panel, and the components within those families.
-A component can then be added to a workflow.