Present:

Mena Radenkovic, Chris Greenhalgh (Nottingham)
Mark Greenwood, Nedim Alpdemir, Robert Stevens, Chris Wroe, PhilLord, Sean Bechhoffer, NickSharman* (Manchester)

* minutes

Agenda:

1. Metadata and the Portal
2. WP 6 - systems application
3. Registry
4. AOB

Minutes (mainly decisions)

Metadata and the Portal

• Decided that all 'Things' in myGrid have UIDs (including ephemeral and mutable things: system/users will need to be aware of mutability).

• Decided that, to avoid myGrid inventing its own general naming scheme, identifiers should be represented by array of strings. String[0] will identify a scope - e.g. LSID, GSH, URL - for the others. Typically array will have just two members, but array allows for compound/nested name schemes.

After the minutes were first written, Chris Greenhalgh commented:

Note: RDF resources are always named by a URI-Reference Does this mean that we should go back to URIs rather than string[] (or String for that matter), and bounce the scope resolution issue to the URIs themselves?! Otherwise I guess we would need a deterministic mapping between our string[] and a URI in order to talk about it in RDF...

• Decided that a standard Port Type (or set of same) should be defined for accessing metadata. Note that this Port Type is implemented by a service that holds metadata about other Things; contrast with GridService^?::GetServiceData which accesses (meta)data held by the service/Thing itself.

• Decided to use triples (specifically, RDF) to hold metadata in myGrid. Sean commented that triples are good for asserting base facts, but less good for anything richer (though as Chris W noted, anything can be forced into triple form).

• Restated commitment to DAML+OIL (eventually OWL) for ontologies.

• Decided to use Jena as repository for RDF & DAML+OIL.

• Decided to use Jena's query language.

• Decided to support the Dublin core schema in the metadata service (though not as an ontology).

The meeting raised the following questions but did not resolve them:

• Who will build a metadata repository service?

• How do we address issues of trust concerning assertions of fact?

• How do ontologies evolve? (related issues: composition, local extension)

• How do we map concepts to concrete data types? Do we need ontological concepts that represent exact data types? Sean Bechhoffercommented that it depended whether the application need to reason over them, using matching/subsumption. Phil suggested we probably did, to see if a service 1's output matched service 2's input exactly, or we needed and had a type-transforming service in between.

Chris Greenhalgh suggested we need a guide to patterns/idioms used in myGrid ontologies, so that more people could build/extend our ontologies. Chris Wroe agree to provide one.

WP 6 - systems application

Carole suggests a LabBook workbench for bioinformaticians (as proposal states).

The proposal includes the following text on the first page of the case for support:

The myGrid project aims to build a demonstrator infrastructure that supports a personalised problem-solving environment for an e-Scientist. The vision is of a “lab book” environment where the e-Scientist can construct in silico experiments, and find and adapt others, store partial results in local data repositories and have their own view on public repositories, and be better informed as to the provenance and the currency of the tools and data directly relevant to their experimental space. The Grid becomes egocentrically based around the Scientist – myGrid. The appropriateness of the infrastructure will be shown in two ways:

• for the e-Scientist by two information intensive demonstration applications in (i) model organism (S. cerevisiae) gene expression analysis, and (ii) GPCR fingerprints database annotation;

• for developers by the assimilation of existing integration platforms found in the Life Sciences, specifically (i) the Sanger Centre’s Distributed Annotation Service (DAS) the EBI’s AppLab and OpenBSA and (ii) the in-house integration platform of GlaxoSmithKline;

The context, the use of the word 'vision' and the quotes around 'lab book' leave a lot of doubt about what this means and/or commits us to. We discussed the following possibilities:

• To develop, from scratch, over myGrid, a lab book application comparable in features (and robustness?) to existing products
  Conclusion: No. Insufficient resources, insufficient research content.

• To integrate an existing lab book product into myGrid
  Conclusion: No. We do not have a supplier as an industrial partner, we do not know of any open source lab books, and we do not have the resources.

• To support in myGrid the basic facilities a lab book would use, namely:
  • traceability through provenance & metadata
  • provision for arbitrary annotation (as 'description' metadata?)
  • managerial sign off - subject to security?
  • ability to construct narratives from the above, for use as a report.
    Conclusion: Yes. First item is part of myGrid's plan now; WP6 are willing to investigate the rest.

Registry

No time.

AOB

No other business.

-- NickSharman - 22 Nov 2002