Skip to end of metadata
Go to start of metadata

Attendees

  • Donal Fellows (UNIMAN)
  • Finn Bacall (UNIMAN)
  • Markus Plangg (TUW)
  • Hélder Silva (KEEPS)
  • Carl Wilson (OPF)
  • Christoph Becker (TUW)
  • Alan Williams (UNIMAN)

Agenda

Current status

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
    • Parameters
      • Some smaller problems when using plugin

Status of myexperiment.org

  • 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 http://www.myexperiment.org/workflows/3426.html

Status of Plato integration

Status of toolwrapper/component publishing

Profiles

Updates to Wiki? http://wiki.opf-labs.org/display/SP/Preservation+Component+Profiles

Other open issues

Dependencies

Currently selecting individuals generated from debian Packages file.

The debian repository only contains stuff packaged by scape, e.g. imagemagick convert wrapped by toolwrapper but not the imagemagick package itself. This is quite restrictive as does not allow to create a dependencies outside of the toolwrapper.

Get licence of packages from Debian repository?

Notes

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?)

Note: it is strongly desired to have one component supporting multiple migration paths. (E.g., imagemagick can convert almost anything to a defined format)

myExperiment status

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

Querying doesn't know ontology at all, and doesn't currently support any query that has anonymous nodes in (i.e., only shallow queries). Finn looking at fixing, but requires improved RDF querying support for Ruby. Carl said in chat that he knows some people to ask.

PLATO integration

Mainly blocked waiting for improved ability to query.

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.)

For now, will use Taverna to do any extraction necessary as it has many suitable shim services (XPath, Beanshell, etc.)

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.)

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.

Information should be attached to the tool service node in the workflow, not to the top level. (Deals with case where multiple tools are used in one component.) Need RDF for doing it, but not expected to be problematic.

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)
ACT.130307.07 Carl: Ask Asger about his changes
ACT.130307.08 Markus: Check if Bolette's changes make sense in detail
ACT.130307.09 Markus: Create characterization example
ACT.130307.10 Markus: Use jplyzer as example (coordinate with Carl, Johann, TUW)
ACT.130307.11 Alan: Update plugin (0.9?)
ACT.130307.12 Alan: SCAPE-specific GUI for migration path & parameters

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.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.