Second provenance challenge - Revision history

Tommy at 13:07, 20 June 2007

2007-06-20T13:07:50Z

← Older revision		Revision as of 13:07, 20 June 2007
Line 67:		Line 67:
	===Benchmark results===		===Benchmark results===

	Although these times are very short, there seem to be two main factors influencing the result: The query engine used and the size of the data. VisTrails is fastest using an XPath processor and a small amount of data. The MyGrid data file is small but it uses a SPARQL server which is slower than using XPath. Southampton uses XPath but has large data files.		Although these times are very short, there seem to be two main factors influencing the result: The query engine used and the size of the data. VisTrails is fastest using an XPath processor and a small amount of data. The MyGrid data file is small but it uses a SPARQL server which is slower than using XPath. Southampton uses XPath but has large data files. These results includes initialization of the wrapper and some extra pre-processing for Southampton to calculate the data links. But they have at most biased the result by a factor of 2.

	==Further Comments==		==Further Comments==

Tommy at 13:03, 20 June 2007

2007-06-20T13:03:35Z

← Older revision		Revision as of 13:03, 20 June 2007
Line 1:		Line 1:
	==Model Integration Results==		==Model Integration Results==

	We have successfully performed the queries using data from VisTrails, MyGrid and Southampton (TBD insert links). We have included our own system because our new query API is general and not native to VisTrails. Our wor is described in our [[~~Pdf~~:pc2.pdf\|Second Provenance challenge]] paper.		We have successfully performed the queries using data from VisTrails, MyGrid and Southampton (TBD insert links). We have included our own system because our new query API is general and not native to VisTrails. Our wor is described in our [[Media:pc2.pdf\|Second Provenance challenge]] paper.

	===Model comparison===		===Model comparison===

Tommy at 13:03, 20 June 2007

2007-06-20T13:03:01Z

← Older revision		Revision as of 13:03, 20 June 2007
Line 1:		Line 1:
	==Model Integration Results==		==Model Integration Results==

	We have successfully performed the queries using data from VisTrails, MyGrid and Southampton (TBD insert links). We have included our own system because our new query API is general and not native to VisTrails.		We have successfully performed the queries using data from VisTrails, MyGrid and Southampton (TBD insert links). We have included our own system because our new query API is general and not native to VisTrails. Our wor is described in our [[Pdf:pc2.pdf\|Second Provenance challenge]] paper.

	===Model comparison===		===Model comparison===

Tommy: /* Benchmark conclusion */

2007-06-20T12:50:29Z

Benchmark conclusion

← Older revision		Revision as of 12:50, 20 June 2007
Line 65:		Line 65:
	1 sec		1 sec

	===Benchmark ~~conclusion~~===		===Benchmark results===

	Although these times are very short, there seem to be two main factors influencing the result: The query engine used and the size of the data. VisTrails is fastest using an XPath processor and a small amount of data. The MyGrid data file is small but it uses a SPARQL server which is slower than using XPath. Southampton uses XPath but has large data files.		Although these times are very short, there seem to be two main factors influencing the result: The query engine used and the size of the data. VisTrails is fastest using an XPath processor and a small amount of data. The MyGrid data file is small but it uses a SPARQL server which is slower than using XPath. Southampton uses XPath but has large data files.


	==Further Comments==		==Further Comments==

Tommy at 12:49, 20 June 2007

2007-06-20T12:49:43Z

← Older revision		Revision as of 12:49, 20 June 2007
Line 31:		Line 31:
	[[Image:model.png]]		[[Image:model.png]]

	===~~The data model~~===		===Scientific Workflow Provenance Data Model (SWPDM)===
	~~Our~~ general provenance model ~~shown above~~ aims to capture entities and relationships that are relevant to both the definition and execution of workflows. The goal is to define a general model that is able to represent provenance information obtained by different workflow systems.		The SWPDM (shown above) is a general provenance model that aims to capture entities and relationships that are relevant to both the definition and execution of workflows. The goal is to define a general model that is able to represent provenance information obtained by different workflow systems.

	===The API===		===The API===

Tommy: /* Translation Details */

2007-06-20T12:34:22Z

Translation Details

← Older revision		Revision as of 12:34, 20 June 2007
Line 31:		Line 31:
	[[Image:model.png]]		[[Image:model.png]]

			===The data model===
	Our general provenance model shown above aims to capture entities and relationships that are relevant to both the definition and execution of workflows. The goal is to define a general model that is able to represent provenance information obtained by different workflow systems.		Our general provenance model shown above aims to capture entities and relationships that are relevant to both the definition and execution of workflows. The goal is to define a general model that is able to represent provenance information obtained by different workflow systems.

			===The API===
	Our model is instantiated as a query API that operates on the concepts in the model. Vertices are modeled as objects and edges as operations on these objects. There also exists more complex operations that can traverse more than one edge which are used to model common provenance query expressions.		Our model is instantiated as a query API that operates on the concepts in the model. Vertices are modeled as objects and edges as operations on these objects. There also exists more complex operations that can traverse more than one edge which are used to model common provenance query expressions.

			===Implementation===
	This API is implemented as wrappers on top of the different data models. These wrapper functions translates the queries into a native query on the source. Currently VisTrails and Southampton uses XML with XPath as the access method. In this case the queries are translated into XPath expressions. MyGrid uses RDF/XML on a SPARQL server and the queries are translated into SPARQL expressions.		This API is implemented as wrappers on top of the different data models. These wrapper functions translates the queries into a native query on the source. Currently VisTrails and Southampton uses XML with XPath as the access method. In this case the queries are translated into XPath expressions. MyGrid uses RDF/XML on a SPARQL server and the queries are translated into SPARQL expressions.


	==Benchmarks==		==Benchmarks==

Tommy at 12:27, 20 June 2007

2007-06-20T12:27:46Z

← Older revision		Revision as of 12:27, 20 June 2007
Line 4:		Line 4:

	===Model comparison===		===Model comparison===
	The VisTrails and MyGrid models were easy to use because of their simple data format, The generalized model of Southampton presented a greater challenge because of the many levels of nesting and		The VisTrails and MyGrid models were easy to use because of their simple data format, The generalized model of Southampton presented a greater challenge because of the many levels of nesting and abstractions. VisTrails required both the execution log and the workflow definition for the provenance queries whereas MyGrid and Southampton only needed the execution log. Finally, VisTrails supports a third level of provenance--the workflow evolution layer, and while we have not used it for this API, it has many benefits when asking queries about differences between workflows.
	abstractions. VisTrails required both the execution log and the workflow definition for the provenance queries whereas MyGrid and Southampton only needed the execution log. Finally, VisTrails supports a third level of provenance--the workflow evolution layer, and while we have not used it for this API, it ~~gives~~ many benefits when asking queries about ~~different workflow versions~~.
			<gallery>
			Image:model_mygrid.png\|MyGrid
			Image:model_vistrails.png\|VisTrails
			Image:model_southampton.png\|Southampton
			</gallery>

	The answers obtained varied depending which information you had access to. E.g. for VisTrails it was not possible to obtain intermediate data items because they are not recorded. In this case the closest answer was the module executions. The queries required the data to contain at least module executions, connections between them and required annotations. These were all present in the models except Southampton who lacked some annotations.		The answers obtained varied depending which information you had access to. E.g. for VisTrails it was not possible to obtain intermediate data items because they are not recorded. In this case the closest answer was the module executions. The queries required the data to contain at least module executions, connections between them and required annotations. These were all present in the models except Southampton who lacked some annotations.
Line 26:		Line 31:
	[[Image:model.png]]		[[Image:model.png]]

	~~<gallery>~~		Our general provenance model shown above aims to capture entities and relationships that are relevant to both the definition and execution of workflows. The goal is to define a general model that is able to represent provenance information obtained by different workflow systems.
	~~Image:model_mygrid~~.~~png\|MyGrid~~
	~~Image:model_vistrails~~.~~png\|VisTrails~~
	~~Image:model_southampton.png\|Southampton~~
	~~</gallery>~~


			Our model is instantiated as a query API that operates on the concepts in the model. Vertices are modeled as objects and edges as operations on these objects. There also exists more complex operations that can traverse more than one edge which are used to model common provenance query expressions.

	~~A description~~ of the ~~system describing Model, API~~ and ~~Implementation?~~		This API is implemented as wrappers on top of the different data models. These wrapper functions translates the queries into a native query on the source. Currently VisTrails and Southampton uses XML with XPath as the access method. In this case the queries are translated into XPath expressions. MyGrid uses RDF/XML on a SPARQL server and the queries are translated into SPARQL expressions.

	any data which was absent from a downloaded model, and whether this affected the possibility of translation or successful provenance query, and any data which was excluded in translation from a downloaded model because it was extraneous_

	==Benchmarks==		==Benchmarks==

Tommy at 11:27, 20 June 2007

2007-06-20T11:27:43Z

← Older revision		Revision as of 11:27, 20 June 2007
Line 25:		Line 25:

	[[Image:model.png]]		[[Image:model.png]]

			<gallery>
			Image:model_mygrid.png\|MyGrid
			Image:model_vistrails.png\|VisTrails
			Image:model_southampton.png\|Southampton
			</gallery>

Tommy at 11:19, 20 June 2007

2007-06-20T11:19:16Z

← Older revision		Revision as of 11:19, 20 June 2007
Line 24:		Line 24:
	==Translation Details==		==Translation Details==

	[[model.png]]		[[Image:model.png]]

Tommy at 11:12, 20 June 2007

2007-06-20T11:12:08Z

← Older revision		Revision as of 11:12, 20 June 2007
Line 23:		Line 23:

	==Translation Details==		==Translation Details==

			[[model.png]]


	A description of the system describing Model, API and Implementation?		A description of the system describing Model, API and Implementation?
Line 53:		Line 56:
	1 sec		1 sec

	===~~Conclusion~~===		===Benchmark conclusion===

	Although these times are very short, there seem to be two main factors influencing the result: The query engine used and the size of the data. VisTrails is fastest using an XPath processor and a small amount of data. The MyGrid data file is small but it uses a SPARQL server which is slower than using XPath. Southampton uses XPath but has large data files.		Although these times are very short, there seem to be two main factors influencing the result: The query engine used and the size of the data. VisTrails is fastest using an XPath processor and a small amount of data. The MyGrid data file is small but it uses a SPARQL server which is slower than using XPath. Southampton uses XPath but has large data files.