FW: IVOA Seattle
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: <Ray.Norris_at_email.protected>
Date: Tue, 3 Dec 2002 10:03:23 +1100
>-----Original Message-----
>From: Tony Linde [mailto:ael_at_EmailProtected]
>Sent: Monday, 2 December 2002 8:37 PM
>To: ivoa_at_EmailProtected
>Subject: IVOA Seattle
[...irrelevant stuff deleted...]
>
>Now for the proposals and these are partly in response to
>Peter's email of 8-Nov:
>
>>> - IVOA procedures and responsibilities should be discussed -
>>> structure, roles, website, etc etc
>
>I agree and would like us to also agree some principles of
>operation, such as:
>
>1. minimalist approach: ie don't define standards unless it
>is absolutely necessary for interoperability
>
>2. we only define standards and only as lower limits: ie
>whatever interfaces we define will allow basic interaction
>but sites are free to implement richer interfaces
>
>3. we see the VO as being implemented bottom-up, by sites
>implementing those components of the VO that allow them to
>participate in whichever activities they wish (no more, no less)
>
>4. the IVOA is not the VO; the VO is not an organisation; the
>VO is not a single or any specific set of sites; the VO is
>diverse and therefore robust in nature
>
>>> - I believe the main focus of the agenda should be the
>>> definition of a complete list of interoperability standards
>
>I've been working for the past few weeks on developing the
>AstroGrid architecture and have identified what I think are
>some of the areas that require IVOA standards so that the
>UK-VO will interoperate with Euro-VO, US-VO etc. Most of this
>comes from a recent focus meeting we held:
>http://wiki.astrogrid.org/bin/view/Astrogrid/FocusVOUsage20021121
>
>This list is obviously incomplete but should serve as a
>starting point for the list we should agree at Seattle. Each
>item on the list will require a working group to define the
>standards themselves. We should agree the core personnel of
>each working group and an email list for each one with
>deadlines for them to produce draft standards.
>
>Perhaps we could create an overall ivoa-stds mailing list now
>and use that to define the list of standards before Seattle.
>Reps from each VO can then come to Seattle with names of
>people from their projects who wish to be on the working
>groups for each standard.
>
>To start with, here is my initial list:
>
>Registry:
>========
>We will want the different forms of resource registries to be
>able to interoperate. It will be up to each VO to decide how
>to store and access their own metadata. Each will also decide
>whether to implement a fine or coarse grained registry. We
>will probably want, however, to store basic metadata for each
>registry entry in *every* registry. We will also need some
>way of uniquely identifying each resource. So, I'd start with
>the following standards:
>
>Registry: Common Metadata (RegCM)
>The minimum metadata required for identification of a
>resource from a simple registry query.
>
>Registry: Resource Address (RegRA)
>A way of uniquely identifying every resource in a registry.
>Perhaps as a corollary to this, we also need some way of
>uniquely identifying every registry or is a registry simply
>another form of resource?
>
>Registry: Interoperability Protocol (RegIP)
>How the different registries interoperate. What types of
>query can they answer from the common metadata, and which
>need feeding on to the parent registry? What form do the
>inter-registry communications take? What form are the results
>returned in? What if a registry is unavailable? Are they mirrored?...
>
>Community:
>=========
>Each VO may choose to manage its communities in different
>ways - we're presently looking at a mix of Globus CAS with a
>MS Passport-like single-signon registration facility (but
>this is still under discussion). So we need some way to
>uniquely identify individuals and groups within each
>community and for the community servers to interoperate. So:
>
>Community: Interoperability Protocol (ComIP)
>How each community works with others. Eg, if a group in one
>community wants to add someone from another community, how do
>the two servers cooperate? If someone from one community logs
>into a portal managed by another community, how do they
>identify themselves and how does the server verify their
>existence in that other community?
>
>Community: Personal Identifier (ComPI)
>A unique address for each person in a community and for the
>groups created by and within that community.
>
>Security:
>========
>Obviously we need some way for the security systems of each
>VO to interoperate, so:
>
>Security: Interoperability Protocol (SecIP)
>Protocol for how widely different approaches to security
>(eg from fully locked-down, certificate only systems to wide
>open, registration not required systems) can recognise and
>verify transmissions from each other.
>
>Resource Centre:
>===============
>This started out life as data centre specific but we'll also
>have centres which provide services rather than data then,
>maybe, centres providing user storage (the AstroGrid MySpace
>concept), centres for holding verified and reviewed
>publications data etc. So I came up with the title of
>resource centre, and:
>
>Resource: Interoperability Protocol (ResIP)
>A web service interface and protocol for accessing the
>resources held by a resource centre: querying what they are,
>accessing them, binding them into workflows, etc
>
>Workflow:
>========
>The goal of everyone building VO components, whether with the
>aim of providing a fully deployable VO or simply a single
>component, should be to allow users to mix and match
>components from multiple software suites in a single workflow. So:
>
>Workflow: Interoperability Protocol (WkfIP)
>Specifying a standard interface that each component that
>could be deployed within a workflow must implement. With
>methods to discover the input and output requirements of the
>component, deployment characteristics, code location and
>platform requirements (if it can be
>redeployed) etc.
>
>
>That's probably enough to get people discussing the list.
>Having said we should aim at a minimalist approach, I seem to
>have set out a lot of standards :) Maybe we don't need them
>all, or they can be boiled down to a single standard for each area.
>
>What does everyone think?
>
>Cheers,
>Tony.
>__
>Tony Linde Phone: +44 (0)116 223 1292
>AstroGrid Project Manager Fax: +44 (0)116 252 3311
>Dept of Physics & Astronomy Mobile: +44 (0)7753 603356
>University of Leicester Email: ael_at_EmailProtected
>Leicester, UK LE1 7RH Web: http://www.astrogrid.org
>
Received on 2002-12-03 10:04:02
Date: Tue, 3 Dec 2002 10:03:23 +1100
>-----Original Message-----
>From: Tony Linde [mailto:ael_at_EmailProtected]
>Sent: Monday, 2 December 2002 8:37 PM
>To: ivoa_at_EmailProtected
>Subject: IVOA Seattle
[...irrelevant stuff deleted...]
>
>Now for the proposals and these are partly in response to
>Peter's email of 8-Nov:
>
>>> - IVOA procedures and responsibilities should be discussed -
>>> structure, roles, website, etc etc
>
>I agree and would like us to also agree some principles of
>operation, such as:
>
>1. minimalist approach: ie don't define standards unless it
>is absolutely necessary for interoperability
>
>2. we only define standards and only as lower limits: ie
>whatever interfaces we define will allow basic interaction
>but sites are free to implement richer interfaces
>
>3. we see the VO as being implemented bottom-up, by sites
>implementing those components of the VO that allow them to
>participate in whichever activities they wish (no more, no less)
>
>4. the IVOA is not the VO; the VO is not an organisation; the
>VO is not a single or any specific set of sites; the VO is
>diverse and therefore robust in nature
>
>>> - I believe the main focus of the agenda should be the
>>> definition of a complete list of interoperability standards
>
>I've been working for the past few weeks on developing the
>AstroGrid architecture and have identified what I think are
>some of the areas that require IVOA standards so that the
>UK-VO will interoperate with Euro-VO, US-VO etc. Most of this
>comes from a recent focus meeting we held:
>http://wiki.astrogrid.org/bin/view/Astrogrid/FocusVOUsage20021121
>
>This list is obviously incomplete but should serve as a
>starting point for the list we should agree at Seattle. Each
>item on the list will require a working group to define the
>standards themselves. We should agree the core personnel of
>each working group and an email list for each one with
>deadlines for them to produce draft standards.
>
>Perhaps we could create an overall ivoa-stds mailing list now
>and use that to define the list of standards before Seattle.
>Reps from each VO can then come to Seattle with names of
>people from their projects who wish to be on the working
>groups for each standard.
>
>To start with, here is my initial list:
>
>Registry:
>========
>We will want the different forms of resource registries to be
>able to interoperate. It will be up to each VO to decide how
>to store and access their own metadata. Each will also decide
>whether to implement a fine or coarse grained registry. We
>will probably want, however, to store basic metadata for each
>registry entry in *every* registry. We will also need some
>way of uniquely identifying each resource. So, I'd start with
>the following standards:
>
>Registry: Common Metadata (RegCM)
>The minimum metadata required for identification of a
>resource from a simple registry query.
>
>Registry: Resource Address (RegRA)
>A way of uniquely identifying every resource in a registry.
>Perhaps as a corollary to this, we also need some way of
>uniquely identifying every registry or is a registry simply
>another form of resource?
>
>Registry: Interoperability Protocol (RegIP)
>How the different registries interoperate. What types of
>query can they answer from the common metadata, and which
>need feeding on to the parent registry? What form do the
>inter-registry communications take? What form are the results
>returned in? What if a registry is unavailable? Are they mirrored?...
>
>Community:
>=========
>Each VO may choose to manage its communities in different
>ways - we're presently looking at a mix of Globus CAS with a
>MS Passport-like single-signon registration facility (but
>this is still under discussion). So we need some way to
>uniquely identify individuals and groups within each
>community and for the community servers to interoperate. So:
>
>Community: Interoperability Protocol (ComIP)
>How each community works with others. Eg, if a group in one
>community wants to add someone from another community, how do
>the two servers cooperate? If someone from one community logs
>into a portal managed by another community, how do they
>identify themselves and how does the server verify their
>existence in that other community?
>
>Community: Personal Identifier (ComPI)
>A unique address for each person in a community and for the
>groups created by and within that community.
>
>Security:
>========
>Obviously we need some way for the security systems of each
>VO to interoperate, so:
>
>Security: Interoperability Protocol (SecIP)
>Protocol for how widely different approaches to security
>(eg from fully locked-down, certificate only systems to wide
>open, registration not required systems) can recognise and
>verify transmissions from each other.
>
>Resource Centre:
>===============
>This started out life as data centre specific but we'll also
>have centres which provide services rather than data then,
>maybe, centres providing user storage (the AstroGrid MySpace
>concept), centres for holding verified and reviewed
>publications data etc. So I came up with the title of
>resource centre, and:
>
>Resource: Interoperability Protocol (ResIP)
>A web service interface and protocol for accessing the
>resources held by a resource centre: querying what they are,
>accessing them, binding them into workflows, etc
>
>Workflow:
>========
>The goal of everyone building VO components, whether with the
>aim of providing a fully deployable VO or simply a single
>component, should be to allow users to mix and match
>components from multiple software suites in a single workflow. So:
>
>Workflow: Interoperability Protocol (WkfIP)
>Specifying a standard interface that each component that
>could be deployed within a workflow must implement. With
>methods to discover the input and output requirements of the
>component, deployment characteristics, code location and
>platform requirements (if it can be
>redeployed) etc.
>
>
>That's probably enough to get people discussing the list.
>Having said we should aim at a minimalist approach, I seem to
>have set out a lot of standards :) Maybe we don't need them
>all, or they can be boiled down to a single standard for each area.
>
>What does everyone think?
>
>Cheers,
>Tony.
>__
>Tony Linde Phone: +44 (0)116 223 1292
>AstroGrid Project Manager Fax: +44 (0)116 252 3311
>Dept of Physics & Astronomy Mobile: +44 (0)7753 603356
>University of Leicester Email: ael_at_EmailProtected
>Leicester, UK LE1 7RH Web: http://www.astrogrid.org
>
Received on 2002-12-03 10:04:02