SDM Provenance - Revision history

Crawl: /* Merged Schema */

2007-06-15T21:47:59Z

Merged Schema

Show changes

Crawl at 19:41, 15 June 2007

2007-06-15T19:41:53Z

Show changes

Crawl: /* Daniel Crawl */

2007-06-15T18:25:31Z

Daniel Crawl

← Older revision		Revision as of 18:25, 15 June 2007
Line 222:		Line 222:
	** Director not the same as a module.		** Director not the same as a module.
	*** Have parameters, but not ports. Either rename module_id column in PARAMETER table to something more general, or create additional PARAMETER tables for directors and workspaces (see below).		*** Have parameters, but not ports. Either rename module_id column in PARAMETER table to something more general, or create additional PARAMETER tables for directors and workspaces (see below).
	** Composite actors are subworkflows.		** Composite actors are subworkflows (hierarchical modeling).
	*** Can have parameters.		*** Can have parameters.
	*** ~~Contain possibly~~ different director.		*** Can contain different director.
	*** Add ~~composite_id~~ column to ACTOR		*** Can contain composite actors (nesting)
			*** Add contained_in_id column to ACTOR, DIRECTOR
			**** foriegn key to COMPOSITE(id)
	* Kepler uses more general relationships (one output, multiple input) than connections (one output, one input) between modules.		* Kepler uses more general relationships (one output, multiple input) than connections (one output, one input) between modules.
	* Wiki says model workflow as DAG? Existing schema does not require this, and Kepler can have cycles.		* Wiki says model workflow as DAG? Existing schema does not require this, and Kepler can have cycles.
Line 243:		Line 245:
	\| id \|\| long		\| id \|\| long
	\|-		\|-
	\| ~~composite_id~~ \|\| long		\| contained_in_id \|\| long
	\|-		\|-
	\|colspan="2" align="center" \| ...		\|colspan="2" align="center" \| ...
Line 257:		Line 259:
	\| id \|\| long		\| id \|\| long
	\|-		\|-
	\| ~~composite_id~~ \|\| long		\| contained_in_id \|\| long
	\|-		\|-
	\|colspan="2" align="center" \| ...		\|colspan="2" align="center" \| ...
Line 270:		Line 272:
	\|-		\|-
	\| id \|\| long		\| id \|\| long
			\|-
			\| contained_in_id \|\| long
	\|-		\|-
	\|colspan="2" align="center" \| ...		\|colspan="2" align="center" \| ...

Crawl: /* Daniel Crawl */

2007-06-15T17:19:06Z

Daniel Crawl

← Older revision		Revision as of 17:19, 15 June 2007
Line 222:		Line 222:
	** Director not the same as a module.		** Director not the same as a module.
	*** Have parameters, but not ports. Either rename module_id column in PARAMETER table to something more general, or create additional PARAMETER tables for directors and workspaces (see below).		*** Have parameters, but not ports. Either rename module_id column in PARAMETER table to something more general, or create additional PARAMETER tables for directors and workspaces (see below).
	** Composite actors ~~(or workspaces)~~ are subworkflows.		** Composite actors are subworkflows.
	*** Can have parameters.		*** Can have parameters.
	*** Contain possibly different director.		*** Contain possibly different director.
	*** Add ~~workspace_id~~ column to ~~MODULE~~		*** Add composite_id column to ACTOR
	* Kepler uses more general relationships (one output, multiple input) than connections (one output, one input) between modules.		* Kepler uses more general relationships (one output, multiple input) than connections (one output, one input) between modules.
	* Wiki says model workflow as DAG? Existing schema does not require this, and Kepler can have cycles.		* Wiki says model workflow as DAG? Existing schema does not require this, and Kepler can have cycles.
	* Need to identify the version of each module (and director) used in a workflow. Is the version incorporated into the id column?		* Need to identify the version of each module (and director) used in a workflow. Is the version incorporated into the id column?
	* ~~I'm a little confused~~ about ~~the tables for~~ workflow evolution~~; a concrete example would help.~~		* Questions about workflow evolution:
	** Shouldn't the foreign key be from ACTION to OPERATION? The same operation can be performed in multiple actions~~, right~~?		** Shouldn't the foreign key be from ACTION to OPERATION? (The same operation can be performed in multiple actions?)
	** Why is object type and parent information in OPERATION?		** Why is object type and parent information in OPERATION?
	* What's an example of an ANNOTATION_EXEC?
	* Modifications to schema:		* Modifications to schema:

Line 239:		Line 238:
	\|		\|
	{\| border="1" cellpadding="3" cellspacing="0"		{\| border="1" cellpadding="3" cellspacing="0"
	\|+ ~~MODULE~~		\|+ ACTOR
	!align="left" \| Column !!align="left" \| Type		!align="left" \| Column !!align="left" \| Type
	\|-		\|-
	\| id \|\| long		\| id \|\| long
	\|-		\|-
	\| ~~workspace_id~~ \|\| long		\| composite_id \|\| long
	\|-		\|-
	\|colspan="2" align="center" \| ...		\|colspan="2" align="center" \| ...
Line 258:		Line 257:
	\| id \|\| long		\| id \|\| long
	\|-		\|-
	\| ~~workspace_id~~ \|\| long		\| composite_id \|\| long
	\|-		\|-
	\|colspan="2" align="center" \| ...		\|colspan="2" align="center" \| ...
Line 267:		Line 266:
	\|		\|
	{\| border="1" cellpadding="3" cellspacing="0"		{\| border="1" cellpadding="3" cellspacing="0"
	\|+ ~~WORKSPACE~~		\|+ COMPOSITE
	!align="left" \| Column !!align="left" \| Type		!align="left" \| Column !!align="left" \| Type
	\|-		\|-
Line 289:		Line 288:
	\| direction \|\| ('in' , 'out')		\| direction \|\| ('in' , 'out')
	\|-		\|-
	\| ~~module_id~~ \|\| long		\| actor_id \|\| long
	\|-		\|-
	\|colspan="2" align="center" \| ...		\|colspan="2" align="center" \| ...
Line 298:		Line 297:
	\|		\|
	{\| border="1" cellpadding="3" cellspacing="0"		{\| border="1" cellpadding="3" cellspacing="0"
	\|+ ~~RELATIONSHIP~~		\|+ RELATION
	!align="left" \| Column !!align="left" \| Type		!align="left" \| Column !!align="left" \| Type
	\|-		\|-
Line 315:		Line 314:
	\| id \|\| long		\| id \|\| long
	\|-		\|-
	\| ~~module_id~~ \|\| long		\| actor_id \|\| long
	\|-		\|-
	\| port_id \|\| long		\| port_id \|\| long

Dakoop: /* Workflow Execution */

2007-06-14T18:38:41Z

Workflow Execution

← Older revision		Revision as of 18:38, 14 June 2007
Line 191:		Line 191:
	\|-		\|-
	\| time \|\| numeric(10,2)		\| time \|\| numeric(10,2)
			\|-
			\| version \|\| long
	\|-		\|-
	\|colspan="2" align="center" \| ...		\|colspan="2" align="center" \| ...

Crawl: added questions about wf evolution

2007-04-26T21:40:45Z

added questions about wf evolution

← Older revision		Revision as of 21:40, 26 April 2007
Line 226:		Line 226:
	* Kepler uses more general relationships (one output, multiple input) than connections (one output, one input) between modules.		* Kepler uses more general relationships (one output, multiple input) than connections (one output, one input) between modules.
	* Wiki says model workflow as DAG? Existing schema does not require this, and Kepler can have cycles.		* Wiki says model workflow as DAG? Existing schema does not require this, and Kepler can have cycles.
	* Need to identify the version of each module (and director) used in a workflow. Is the version incorporated into the id column?		* Need to identify the version of each module (and director) used in a workflow. Is the version incorporated into the id column?
			* I'm a little confused about the tables for workflow evolution; a concrete example would help.
			** Shouldn't the foreign key be from ACTION to OPERATION? The same operation can be performed in multiple actions, right?
			** Why is object type and parent information in OPERATION?
			* What's an example of an ANNOTATION_EXEC?
	* Modifications to schema:		* Modifications to schema:

Crawl at 20:30, 23 April 2007

2007-04-23T20:30:08Z

← Older revision		Revision as of 20:30, 23 April 2007
Line 226:		Line 226:
	* Kepler uses more general relationships (one output, multiple input) than connections (one output, one input) between modules.		* Kepler uses more general relationships (one output, multiple input) than connections (one output, one input) between modules.
	* Wiki says model workflow as DAG? Existing schema does not require this, and Kepler can have cycles.		* Wiki says model workflow as DAG? Existing schema does not require this, and Kepler can have cycles.
			* Need to identify the version of each module (and director) used in a workflow. Is the version incorporated into the id column?
	* Modifications to schema:		* Modifications to schema:

Chin: /* George Chin */

2007-04-11T21:32:15Z

George Chin

← Older revision		Revision as of 21:32, 11 April 2007
Line 328:		Line 328:

	*Would be useful for wf_exec and module_exec to have a "status" field for capturing execution progress.		*Would be useful for wf_exec and module_exec to have a "status" field for capturing execution progress.

			*module_exec should also have machine fields (machine_os, machine_proc, machine_ram) because different modules of same workflow may be running on different computers.

	*Other provenance systems such as MINDSWAP and MYGRID use ontologies to organize objects/actors. Should we consider using ontologies or semantic hierarchies to capture the structures and relationships of elements such as actors, parameters, ports, and data? This would facilitate more sophisticated querying and could provide the application developer/scientist more semantic information that could aid in workflow design by better identifying which parameters and ports are compatible, which actors have similar I/O requirements, how to transform data between actors, etc. Would Vistrails’ data model with its use of generic modules that can pretty much be anything constrain our ability to use ontologies?		*Other provenance systems such as MINDSWAP and MYGRID use ontologies to organize objects/actors. Should we consider using ontologies or semantic hierarchies to capture the structures and relationships of elements such as actors, parameters, ports, and data? This would facilitate more sophisticated querying and could provide the application developer/scientist more semantic information that could aid in workflow design by better identifying which parameters and ports are compatible, which actors have similar I/O requirements, how to transform data between actors, etc. Would Vistrails’ data model with its use of generic modules that can pretty much be anything constrain our ability to use ontologies?

Chin: /* George Chin */

2007-04-11T21:28:19Z

George Chin

← Older revision		Revision as of 21:28, 11 April 2007
Line 326:		Line 326:

	*What can annotations be attached to? I can imagine one wanting to stick annotations on workflows, modules, connections, ports, and parameters, and annotation_exec on both workflow_exec and module_exec.		*What can annotations be attached to? I can imagine one wanting to stick annotations on workflows, modules, connections, ports, and parameters, and annotation_exec on both workflow_exec and module_exec.

			*Would be useful for wf_exec and module_exec to have a "status" field for capturing execution progress.

	*Other provenance systems such as MINDSWAP and MYGRID use ontologies to organize objects/actors. Should we consider using ontologies or semantic hierarchies to capture the structures and relationships of elements such as actors, parameters, ports, and data? This would facilitate more sophisticated querying and could provide the application developer/scientist more semantic information that could aid in workflow design by better identifying which parameters and ports are compatible, which actors have similar I/O requirements, how to transform data between actors, etc. Would Vistrails’ data model with its use of generic modules that can pretty much be anything constrain our ability to use ontologies?		*Other provenance systems such as MINDSWAP and MYGRID use ontologies to organize objects/actors. Should we consider using ontologies or semantic hierarchies to capture the structures and relationships of elements such as actors, parameters, ports, and data? This would facilitate more sophisticated querying and could provide the application developer/scientist more semantic information that could aid in workflow design by better identifying which parameters and ports are compatible, which actors have similar I/O requirements, how to transform data between actors, etc. Would Vistrails’ data model with its use of generic modules that can pretty much be anything constrain our ability to use ontologies?

Chin: /* George Chin */

2007-04-11T21:17:01Z

George Chin

← Older revision		Revision as of 21:17, 11 April 2007
Line 324:		Line 324:
	====George Chin====		====George Chin====
	*Agree with David that we need a mechanism to represent subworkflows, although not crazy about the term "workspace".		*Agree with David that we need a mechanism to represent subworkflows, although not crazy about the term "workspace".

			*What can annotations be attached to? I can imagine one wanting to stick annotations on workflows, modules, connections, ports, and parameters, and annotation_exec on both workflow_exec and module_exec.

	*Other provenance systems such as MINDSWAP and MYGRID use ontologies to organize objects/actors. Should we consider using ontologies or semantic hierarchies to capture the structures and relationships of elements such as actors, parameters, ports, and data? This would facilitate more sophisticated querying and could provide the application developer/scientist more semantic information that could aid in workflow design by better identifying which parameters and ports are compatible, which actors have similar I/O requirements, how to transform data between actors, etc. Would Vistrails’ data model with its use of generic modules that can pretty much be anything constrain our ability to use ontologies?		*Other provenance systems such as MINDSWAP and MYGRID use ontologies to organize objects/actors. Should we consider using ontologies or semantic hierarchies to capture the structures and relationships of elements such as actors, parameters, ports, and data? This would facilitate more sophisticated querying and could provide the application developer/scientist more semantic information that could aid in workflow design by better identifying which parameters and ports are compatible, which actors have similar I/O requirements, how to transform data between actors, etc. Would Vistrails’ data model with its use of generic modules that can pretty much be anything constrain our ability to use ontologies?