OGSA Teleconference - 2 August 2007 - Information Services
==========================================================

* Participants

  Mike Behrens (R2AD LLC)
  Donal Fellows (UMAN)
  Chris Kantarjiev (Oracle)
  Hiro Kishimoto (Fujitsu)
  Shiraz Memon (Julich)
  Andreas Savva (Fujitsu)
  Dave Snelling (Fujitsu)

  Minutes: Andreas Savva

* Agenda Bashing

  - Discussed whether to have a meeting or not since the authors are
    not present on the call. Agreed to discuss the document anyway.

* Minutes June 7 approved with no changes

* Action Items Review 

> AI-0607c: Laurence will write up (a) small chart of what
>         this design team will do (plan or schedule) and, (b) generic
>         information services architecture in a simple chart.

  Leave the action open since only part of it is addressed in the
  current draft.

* Document review and discussion

** Common query interface or not

  - It is a good idea. 
  - Should it be a single or multiple, e.g., LDAP or XML-based
    query interface?
  
  It could be structured as one abstract interface specification and
  then different concrete renderings for each one

  Discussed query interface characteristics. 
  - Incremental result return as one requirement
  - The RSS-WG is one group that has requirements or can be thought of
    as a specialized query interface.
  - Suggestions to look at ODBC etc, OGSA-DAI renderings may be
    similar to this
  - WS-Enumeration was mentioned, for incremental results
  - WSRF and representing result set as a resource

  There seems sufficient interest to look for use cases and
  requirements. Identified three topics:
  - Query interface
  - Query language (XQuery as one possible first candidate; rich enough)
  - Information model (schema candidate is the GLUE-WG work)

  Does the document address sufficient level of requirements?
  - LDAP is the focus, which is a concern
  - Necessary but not sufficient level of requirements

  Complexity of glue schema and what kind of queries to be expressed?
  Not sure yet
  
  The query interface is ongoing work that seems to be touching on a
  number of these areas
  - A seemingly good approach is to allow for the continued
    experimentation (since there is a lot of work in flight) and wait
    for results before continuing with the definition of a common
    query interface.
  
  Feedback is that the interface should be compatible with choice of a
  glue information model with xquery

  - Volunteers for providing use case for enterprise etc
    - None on the call

** Standardize endpoint of registry

  No clear distinction between this interface and the query interface?
  - The place where to ask the query
  - Common query interface should be able to handle it?

  Enough information to identify the thing in question

  1. Registry of endpoints is application of common interface
  2. The registration of content is separate? It does not look like it
     is addressed in the document

     Document seems to address only pull model (page 7) rather than
     push which would require registration

  - Discussed nomenclature: registry vs catalogue; and semantics of these.
  - Entity supporting query interface vs registry difference