Minutes of the OGSA Data WG F2F meeting, 16th January 2006.
Sunnyvale, California

* Roll Call
Dave Berry, NeSC (note taker)
Chris Jordan, SDSC
Mario Antonioletti, EPCC

Apologies from Allen Luniewski, who is ill.


We discussed data access & files, also scope of data access.

- The document should flag areas where work is needed for a generic framework.  E.g. a set of URIs to describe data formats and query languages, with some URIs predefined and the ability for users to define their own.  We might want to use MUST/SHOULD language.

- We need a metadata schema for describing files.

_ We need an interface for extracting files from a file system; we need to think carefully about where this fits in the overall architecture (e.g. storage management, data access, or a  new section).  We hope that replication could then be a single service that uses the file access and metadata services.

- We need to better define the scope of data access.  E.g. one definition could cover just direct request/response. The DAIS factory pattern would then be in a separate section (called data selection?).  This separation might simplify the extension of this work to include the extraction of files from a file system.  Alternatively we could include the factory pattern and 3rd-party deliver in the same section.  For version 1, we could introduce the patterns and then say that we only address the first.

- We need to decide how data transfer integrates with data access in order to achieve 3rd-party delivery.

- We discussed access control for a distributed file system, and agreed that our aim should be to use the OGSA authorisation system to control access, rather than add ACLs to the metadata.  Obviously the data storage resources may have local access control mechanisms that will need to be mapped to the Grid level ones.

We discussed how to use Reagan's contribution.

- We agreed that SRB is a useful source of information as a working complex data architecture that addresses the needs of several real projects.  Many or most of the commands will have counterparts in our architecture (though not all).

- Reagan's list of commands clearly covers more functionality that data access; in fact it covers more than grid file systems, with significant overlap with storage management.  So we can't use his list as part of a single section of the document.

- SRB supports many use cases, so it would not be appropriate to use the list as one of our scenarios.

- It would definitely be useful to analyse the list of commands and try to map them to functionality in our architecture, i.e. to use it as a test.  This is likely to point out gaps in our architecture.