Notes from Session 1 GWS Interop Cambridge 2007

VOSpace 1.0 Core Metadata

The metadata are not to be treated as mandatory in the sense that they must all be supplied for every node, but is to be thought of as mandatory in the sense that if the conept is used then it should use the following metadata identifers.

Properties

• Modification Date
• Creation Date - but what about replicas?
• Owner
  • how does this fit in with ACLs - is a single owner meaningful or sensible in the long term? Perhaps this should always be a group.
  • what identifier is to be used for the user?
  • like the curator
• group -?? better than owner?
• Size
  • works for the "unstructured data" - not so clear for structured data where the size would be dependent on the representation
  • perhaps size should be the size that would be used in a "quota" calculation - but unclear how this would be represented
• md5sum - for looking

Protocol identifiers

• https-put
• https-get
• http-get
• http-put
• gridftp
• file
• scp
• rsh

Data format Identifiers

deferred

Metadata for the VOSpace.

• Access control for the VOSpace as a whole.
• notion of capacity
• quota enforced or not?
• strutured or not?
• volatility/retetion period

VOSpace 1.1

Logical storage units vs. alternative serice interfaces

general agreement that the original purpose of vospace was to provide a logical view, and not physical view of the data. So it was fe

Implementers of VOSpace on top of SRB.

With a view to collaborate and/or adopt another implementation.

• Andre Schaaff - working with French high energy physics.
• CCLRC - Adil Hasan
• SDSC - themselves
• Richard Wagner - UCSD

--++Action Items

1. look for inspiration from the HTTP Headers & Dublin core. - publish a list - 31-Oct
2. Mail all the people planning to implement a VOSpace on SRB.