Version 1 by Donal Fellows
on Mar 07, 2013 14:16.

compared with
Current by Donal Fellows
on Mar 07, 2013 14:47.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (31)

View Page History
h2. Attendees

* Donal Fellows (UNIMAN)
* Finn Bacall (UNIMAN)

h2. Agenda

h3. Current status

h4. Status of the Taverna plugin

* [Last published version|] is 0.2\\
Allows to select individuals, issues with permissions of published components, Missing SCAPE specific GUI.
* [Latest source|] is 0.3-SNAPSHOT\\
Allows selection of permissions. Missing SCAPE specific GUI?
** Migration Paths

h4. Status of

* Sandbox vs normal version?\\
Which should we use for testing?
* Sandbox\\
Newer REST version on sandbox? Taverna plugin cannot "Copy component" to sandbox. Upload via webpage shows 500 error.
* Normal\\
Query does not find components: e.g. [this query|] should find []

h4. Status of Plato integration

h3. Profiles
Updates to Wiki?

Updates to Wiki? []

h3. Other open issues

h4. Dependencies

Currently selecting individuals [generated from debian Packages file|].

h2. Notes

h3. Taverna Component Plugin status

Work in progress, mainly on addressing how to deal with publishing a component with an appropriate license. Release policy complex because of coupling to myExperiment updates. Markus is experimenting with 0.3-SNAPSHOT version retrieved from source repo. Work required on supporting open-world properties (i.e., string valued or string+defined sample values). Support for complex properties requires a SCAPE-specific plugin? (What happened to the proof of concept stuff that David was working on? Was it just demonstrating viability of the SPI for refined GUIs?)

h3. myExperiment status

Sandbox is ahead of main site, but has some 500 failures. Still, use that for testing.

h3. PLATO integration

Mainly blocked waiting for improved ability to query.

h3. Toolwrapper/Component publishing

Possible issue to do with addition of description *how* to do extraction of metrics from characterization tools; should this go in the component or be done externally? (If the former, the input descriptor document needs to give the information.)

h3. Updates to Wiki

Substantial amount of text was deleted from page by Asger Blekinge; need to review those changes. (Main change appears to be removal of “Quality assurance property comparison component” section; is this something we desire? Can't just roll back; there are subsequent less-controversial changes by someone else.)

h3. Dependencies

How to gather information about what debian packages are depended-upon and to put that information in the component (so that tools can query over it). Package names and versions are not closed-world entities; licenses *are* closed-world (or at least we can maintain a list). License information cannot come from Debian package descriptors (which just don't have the info, unlike with RPM spec files) but they are described in the SCAPE toolwrapper/component descriptor.

h2. Actions

{{ACT.130307.01}} _Finn_: Give estimate for how long it will take to improve querying over RDF in myExp. (Key Q: In time for us to demo at review or not?)
{{ACT.130307.02}} _Finn_: Check whether myExp supports OR queries (needed for component license checks given that there's no ontology support)
{{ACT.130307.03}} _Finn_: Check timeline for updates to myExp; when will things go live?
{{ACT.130307.04}} _Finn_: Allow myExp to tolerate anonymous nodes; mustn't crash\!
{{ACT.130307.05}} _Finn_: Solution for how to do SCAPE-specific queries for review.
{{ACT.130307.06}} _Carl_: Review wiki changes properly (also _Markus_)

h2. Decisions

{{DEC.130307.01}}: Location of tool description RDF in component workflow: on tool, not on workflow.
{{DEC.130307.02}}: Keep components that wrap tools simple prior to review.