This loads a font easier to read for people with dyslexia.
This renders the document in high contrast mode.
This renders the document as white on black
This can help those with trouble processing rapid screen movements.

FW: IVOA Seattle

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