Participants At SGT

Archie Warnock, AWCubed
William Chen, SGT
Ananth Rao, SGT
John Evans, GST
George Percivall, GST
Allan Doyle, International Interfaces
Doug Nebert, FGDC
Jeff de La Beaujardiere, NASA
Lou Reich, CSC

Larry Bouzane, Compusult
David O'Mahony, Compusult
Serge Margoulies, Ionic
Yonsook Enloe, SGT
Arliss Whiteside, BAE SYSTEMS

Note: This material is highly related to (or inseparable from) the BSM.

Note: There's probably going to have to be a fork: BSM looking forward to WMT-3 (i.e. this group), Common Elements for June (i.e. Jeff); and we need a story that relates all this together (i.e. Allan et. al.).

Note: BSM = tightly coupled to data, GSM = loosely coupled to data - look at 19119 and get comments in to George.

Tentative Next Meeting: April 19, 1000-1400 (US EDT = GMT-4)- Need OGC to set up a telecon

Subject: Agenda and thoughts for WRS meeting/telecon
   Date: Tue, 27 Mar 2001 18:43:48 -0500
   From: Lou Reich <louis.i.reich@gsfc.nasa.gov>
   To: Allan Doyle <adoyle@intl-interfaces.com>, Serge.Margoulies@ionicsoft.com
   CC: Doug Nebert <ddnebert@fgdc.gov>, Jeff de La Beaujardiere <delabeau@iniki.gsfc.nasa.gov>,
   "A. Rao" <arao@sgt-inc.com>, percivall@gst.com, barry@compusult.nf.ca,
   larry@compusult.nf.ca, ddnebert@fgdc.er.usgs.gov, warnock@awcubed.com,
   yonsook@harp.gsfc.nasa.gov, kurt@opengis.org, Arliss.Whiteside@baesystems.com,
   rob@socialchange.net.au, loureich@att.net, Bernard.Snyers@ionicsoft.com,
   Benoit.Borlee@ionicsoft.com

 I propose the following agenda for the WRS meeting/telecon. I have 
   also supplied many of the emails that I have received to act as 
   source material for the meeting. If anyone wants to propose 
   reshuffling the topics due to their timezone or availability please 
   send email to the group. I have tried to organize this by putting the 
   finite issues first.

   WRS Meeting Agenda:

9:30-10:15 Usability/Interoperability of current Stateless Catalog Prototypes

 Source Material - Jeff D. email - People are willing to implement a lot of this in April
   Goal: Answers to each issues with proposed timelines for implementation
   Proposed Discussion Leader: Jeff D

Topic: Discussion about WMS layers as a Filter expression on WFS.

- this is really the SLD paradigm.

Need to handle this in the catalog. - i.e. need to know which layers can take a WFS Filter expression

Topic: WFS as Catalog. Explanation of use of WFS as a Catalog by Serge. Implication is that a catalog entry is a feature. Problem is that catalog entries have geometries. Service Registry entries may not have geometries. GML does not require a Feature to have a Geometry. Lou argues that there are different semantics on a catalog than you would infer on a WFS. We have to remember that our goal is to unbundle interfaces and reuse the ones we have. We want to find interfaces that can be generalized to other cases. Let's look at our terminology vs. the more general IT terminology. Why have "Getfeature" when the rest of the world has "GetObject" and "Filter" when the rest of the world says "Query"?

Caution is that we should not "automatically generalize beyond Geospatial". Reuse is a qualtiy, but look at understandibility & usability as factors.

Topic: GetCapabilities is hard to do.

1. What if we have a "static" form of GetCapabilities, i.e. service providers publish the full URL, not just the prefix. The issue is that now we have

<prefix>REQUEST=Capabilities&WMTVER=1.0.0

<prefix>REQUEST=GetCapabilities&VERSION=1.0.7

<prefix>REQUEST=GetCapabilities&SERVICE=WMS&VERSION=1.0.7

it's hard to figure out what to tack onto the prefix anymore. If we have a convention of always providing the full URL for Capabilities, then we can find the rest of the service entry points. Having to guess/intuit the capabilities entry point is hard. This would also imply that every server must support GetCapabilities via GET, which also is important.
 
2. We have to come to grips with whether we're going to require SERVICE= or not. I don't think we have full consensus on that yet.

We should push hard to get everyone up to the same level and get them thinking hard about this material before the start of the next testbed.

!0:30 -12:30 Scope of WRS within OGC Web Services Framework

Lou has been working on a Stateless Catalog "profile" instead of integrating it into the Catalog Services document. It became apparent that the "registry" aspects wer important (e.g. "harvest", "push", "pull" of the service metadata). (See point 5 below)

 Source material: WRS Spec discussion Paper
   Emails from Doug N, Jeff D on Catalog Services vs Stateless
   Catalog Prototypes/profiles vs WRS
   Emails from Serge on WFS vs WRS
   My comments inserted here:
   1. I think WFS can serve as an underlying engine for WRS
   as can the Compusult and SGT Statefull Catalog
   implementation or a GEO/CIP server
   2. I believe the audience for the WRS searches is people
   either behind smart or thin clients
   3. I believe XML is a very valid technology for
   returning results and XML Schema is a good technology
   for specifying standard result set formats, I am not
   sure that GML 2.0 is the best tools particularly if
   we use the concept of "domain independence" from the
   OGC Catalog Services Spec
   4. We need to define the scope and robustness of a WRS.
   The current Catalog Spec is "domain independent" while
   the current Stateless Prototypes are HTTP GET and
   tailored to WMS and hardwired
   5. I think the prototype efforts have shown that a major
   selling point of Stateless Catalogs is their capability
   to pull metadata from service providers. OGC Catalog
   Spec v 1.0 and 1.1 does not deal with these issues
   Goal: A common understanding of the issues to enable further discussion
   Proposed Discussion Leaders:Doug Nebert/ Lou Reich

Topic: Integration Issues
We need to talk about how to integrate this material into a real information infrastructure. Doug would like to have an integrated catalog proposal that we can send to ISO as an initial draft. It can change later. We also need a type registry. We need an SRS registry.

Lou thinks it's important to keep the term "Registry Services" as a name for the push/pull harvesting.

Allan thinks Lou is conflating mechanism and policy. Lou's description of Registry Services includes schemas and obligations to keep things updated, etc. Lou says that OGC has to provide a very good template of how to do this instead of just building a box full of parts.

We have to explore the raw materials we have before we lock ourselves into any firm direction. If we call it catalog services we have to make some changes to the catalog spec.

It would be good to prototype a Capabilities for a Catalog.

We need to develop a more mature understanding of the relationship between data and services. A large community wants to find data and then use a service to act on the data. Others want to find services w/o worrying about the data. (Scientist vs. Mapquest user)

We want to set up an "OGC Web Services" information community to test this stuff out.

Action: Develop a version of a BSM oriented Catalog spec that deals with only coarse-grained catalog services and includes stateless and stateful modes. Question is how we approach this vis a vis ISO. Doug and Lou to develop an annotated outline of the new spec. (April 13).
 
 

1:30 - 2:30 BSM/GSM and Web Service metadata in general
   Goals: Start a discussion which leads into pre-WMT3 BSM 
   Specification effort
   Proposed Discussion Leaders: Allan Doyle/Jeff D/George Percivall

   At 8:16 AM -0500 3/22/01, Allan Doyle wrote:
   >I was hoping we could talk about this in Liege in the WWW Mapping 
   >SIG, but I like Serge's idea of setting aside another room and
   >time to discuss this. I think we need to spend as much time on this 
   >as we can.
   >
   >Serge.Margoulies@ionicsoft.com wrote:
   >
   > > I agree that we have to clarify. I have another view of this.
   > >
   > > We now have a Web Feature Specification which is a general feature    Store
   > > with transactional interface.
   > > This means that simple or complex features can be defined in XMLSchema
   > > ant there is a complete standard interface to
   > >
   > > - getCapabilities : which will give a list of featureTypes supported    by
   > > this server
   > > in our case, we will have to define the base feature types and
   > > extend them for each type of services.
   > > - describeFeatureType which can return the featureTypes Schema
   > > for one or more selected featureType.
   > > - a getfeature to make queries on the featureStore. The basic filter/query
   > > language
   > > is compliant with OGC query language but it has extensions to be able    to do
   > > more complex
   > > things if needed, to manage sub collections, to insert in sub collections,
   > > etc...
   > > and return GML2.
   > > - a transaction interface to insert, delete, update features in the    store
   > > - a lock interface to lock objects.
   > > - a http get and http post interface.
   > >
   > > I still wonder why we need other OGC interfaces if we have a coherent    set
   > > with these.
   > >
   > > Our work would then be to define the featureTypes Schemas we need
   > > (work has already been started in the catalog/capabilities/wrs...)
   > >
   > > Then we will need to decide if the ServiceRegistry is a mecanism
   > > in which we subscribe by sending the information on it's bootstrap
   > > (capabilities url ) and it's up to the catalog to treat them and populate
   > > the registry or if the catalog accept to be populated direclty by    feature
   > > instances describing the server.
   > >
   > > So we have to clarify more then catalog vs registry
   > > We have to understand where WFS interfaces stands and clarify
   > > - WFS filter vs catalog filter
   > > - WFS GML output vs catalog output
   > > - WFS transactional interface vs catalog/registry interfaces
   > >
   > > I think they are more general and more suited to be the web interfaces
   > > over legacy catalogs.
   > >
   > > Anyway, we have to discuss the idea that a WFST could be a valid
   > > catalog and define how.
   > >
   > > We could also have an other meeting in Liege during TC
   > > with this small group. I can provide the meeting room.
   > >
   > > Serge
   > >
   > > 
   >---------------------------------------------------------------------- 
   >-------------------
   > >
   > > Serge MARGOULIES - CEO - IONIC Software s.a.
   > > Rue de Wallonie, 18
   > > B-4460 Grâce-Hollogne
   > > Belgium
   > > Phone: +32.4.3640364
   > > Fax: +32.4.2534737
   > > Mobile: +32.476.396851
   > > Email: serge.margoulies@ionicsoft.com
   > > Web: http://www.ionicsoft.com
   > >
   > >
   > > Doug Nebert
   > > <ddnebert@fgd To: Jeff de La 
   >Beaujardiere <delabeau@iniki.gsfc.nasa.gov>
   > > c.gov> cc: "A. Rao" 
   ><arao@sgt-inc.com>, percivall@gst.com, barry@compusult.nf.ca,
   > > larry@compusult.nf.ca, 
   >ddnebert@fgdc.er.usgs.gov, warnock@awcubed.com,
   > > 21/03/01 
   >Serge.Margoulies@ionicsoft.com, yonsook@harp.gsfc.nasa.gov, 
   >adoyle@intl-interfaces.com,
   > > 23:23 kurt@opengis.org, 
   >rob@socialchange.net.au, Arliss.Whiteside@baesystems.com, Lou Reich
   > > 
   ><louis.i.reich@gsfc.nasa.gov>, loureich@att.net
   > > Subject: Re: Web 
   >Registry Service Meeting Proposal
   > >
   > >
   > > Jeff de La Beaujardiere wrote:
   > > >
   > >
   > > I am concerned that once was clearly called a Stateless Web
   > > Profile for Catalog Services has been relabelled as a Web Registry
   > > Service. In my mind a registry service will be used for many things,
   > > mostly for locating class-level definitions in a community (e.g. the
   > > definition of a service name, a parameter code list, etc.).
   > >
   > > Catalog services build on registries (namespaces) to support the
   > > inventory searches for instances of data or services. In either event,
   > > having more than one method to perform catalogue-like searching is
   > > ill-advised. We need to consolidate these things quickly. Perhaps
   > > a Web Registry Service is a specialization of a Catalog Service?
   > > If not, we'll be in for a rocky ride. We should consider the http
   > > approach for catalog services to be part of the catalog services spec
   > > with specializations for data, registry, or service instance discovery.
   > >
   > > I will plan to be there on the 28th at SGT.
   > >
   > > Doug.
   > >
   > > > A Rao writes:
   > > > > The topics for discussion (extracted from the WRS
   > > > > discussion paper) are as follows (but not limited to):
   > > >
   > > > Ananth, Barry, Larry, Allan, Lou et al.-
   > > >
   > > > I still have some disagreements (see below) with the content
   > > > of the results returned by the existing Catalogs, and hope we
   > > > can fix them before they become immortalized in the WRS
   > > > specification.
   > > >
   > > > I've mentioned these before on various occasions. Please let
   > > > me know if you feel the concerns are wholly unwarranted, in
   > > > which case I'll stop nagging, or if you concur that the
   > > > problems are legitimate usability and accuracy issues.
   > > >
   > > > In order of severity:
   > > >
   > > > 1) Where is the equivalent of the WMS 1.0    element
   > > > <Service><Title>? The <Abstract> is there between
   > > > <citation> and <pointOfContact>, but not the <Title>.
   > > > The Service Title identifies the data server.

   > > >
   > > > 2) Why is the aformentioned abstract seemingly derived from
   > > > <Service><Abstract> in the SGT response, but
   > > > <Layer><Abstract> in Compusult's? I believe
   > > > <Service><Abstract> is correct for the high-level
   > > > attribution (but see #3 for why this attribution is wrong),
   > > > and that <Layer><Abstract> should be part of the    Layer
   > > > metadata in the operations section (but see #5 regarding the
   > > > lack of such ancillary information in the operations section).

   > > >
   > > > 3) Attribution info is SGT's or Compusult's, not original
   > > > layer provider's. I need something to show my human user
   > > > what the source of the layer is to assist in making a
   > > > choice. For example, this is wrong:
   > > > <citedResponsibleParty> <!-- @ Compusult -->
   > > > <individualName>Jason MacDonald</individualName>
   > > > <organisationName>Compusult Limited</organisationName>
   > > > <positionName>Software Engineer</positionName>
   > > > <!-- et cetera -->
   > > > <roleCode value="contentProvider"/>
   > > > </citedResponsibleParty>
   > > > <!-- et cetera -->
   > > > <connectPoint> <!-- @ Cubewerx -->
   > > > <linkage xmlns:xlink="http://www.w3.org/1999/xlink"    xlink:type
   > > ="simple" xlink:href="http://www.cubewerx.com/wmt/cubeserv/cubeserv.cgi?"/>
   > > > </connectPoint>

   > > >
   > > > 4) Can we add to Layers, Feature Collections and Coverages a
   > > > 'cascaded' attribute that is 0 by default and increments by
   > > > 1 every time the object is cascaded. Also, can Catalogs
   > > > offer the option to search only for non-cascaded objects.
   > > > This would prevent the duplication and ambiguity we're
   > > > seeing in responses.

Let's add some additional elements that indicate Source URL and Source title. If you casccade, increment the flag, add to the source URLs. Jeff to write this up.

   > > >
   > > > 5) Other useful metadata is missing, including: Layer
   > > > <Abstract>, <BoundingBox>, <Attribution>, <FeatureList>,
   > > > <ScaleHint>; Style <Abstract>, <LegendURL>,    <StyleSheetURL>.
   > > > Perhaps this is the fault of 19119's operation parameter
   > > > listing, because it gives only values and valueTitles and
   > > > doesn't have a clear place (AFAIK) for ancillary metadata
   > > > about the value choices. Given that the Catalog has
   > > > ingested all this useful info, can it also spit it back out
   > > > in a "full" response?

Note that full records are "unrolled" layers from the WMS hierarchical layers. We need to fully explore the implications of WMS vs. "Web Layer Service"

   > > >
   > > > Thanks,
   > > > Jeff DLB
   > > >
   > > > Dr Jeff de La Beaujardiere
   > > > NASA Goddard Space Flight Center * Code 933
   > > > delabeau@iniki.gsfc.nasa.gov * +1 301 286 1569
   > > > Digital Earth * www.digitalearth.gov
   > >

   > > --

   Hi,

Compusult will dial in to participate in this meeting on Web March 28th.
   Please provide the dial-in instructions when they become available.

There are several issues being raised in response to this request for a
   meeting which will help set the agenda. We will review these and provide
   our opinions before the meeting.

Regards,

Larry

----- Original Message -----
   From: "A. Rao" <arao@sgt-inc.com>
   To: <percivall@gst.com>; <barry@compusult.nf.ca>; <larry@compusult.nf.ca>;
   <ddnebert@fgdc.gov>; <warnock@awcubed.com>;
   <Serge.Margoulies@ionicsoft.com>; <yonsook@harp.gsfc.nasa.gov>;
   <adoyle@intl-interfaces.com>; <delabeau@iniki.gsfc.nasa.gov>;
   <kurt@opengis.org>; <rob@socialchange.net.au>;
   <Arliss.Whiteside@baesystems.com>
   Cc: "Lou Reich" <louis.i.reich@gsfc.nasa.gov>; <loureich@att.net>
   Sent: Tuesday, March 20, 2001 8:08 PM
   Subject: Re: Web Registry Service Meeting Proposal

   > Hi--,
   >
   > The meeting has been tentatively scheduled for Wed. March 28 from 9.30    AM
   > to about 12.30PM here at SGT headquarters in Greenbelt. Directions to our
   > facility are enclosed in the Word document. For those of you who wish to
   > call in, I'll post the number and password when they become available.
   >
   > The topics for discussion (extracted from the WRS discussion paper) are
   > as follows (but not limited to):
   >
   > - Do others agree with this view of the evolution of the Stateless
   > catalogs into a Web Registry Service with service description
   > registration and update as a formal interface and the use of
   > GetCapabilities to substitute for the Explain capabilities in the OGC
   > Catalog Specification
   > - Will the same service registry catalog WMS, WFS and WCS. If so how
   > different are the metadata. For example is a Feature Type or a Feature
   > Collection the correct granularity for a registry descriptor and how does
   > it's metadata vary from that of a mapping layer.
   > - If we decide that the Registry descriptors need an incremental
   > update service for scalability, can service providers use the WFS
   > transaction interface to specify the required updates.
   > - The specification of the Registry descriptor contents and schema
   > are equivalent/dependant on the same research as the Basic/General
   > Services Model. How should the the two efforts interact.
   > - Is the full GetDescriptor service interface acceptable for
   > lightweight clients or should we maintain a GetDescriptors profile with
   > defaults similar to those of the Stateless Catalog prototypes.

> > Douglas D. Nebert
   > > Geospatial Data Clearinghouse Coordinator
   > > FGDC/GSDI Secretariat Phone: +1 703 648 4151 Fax: +1 703
   > > 648-5755
   > > Pager Messaging: http://clearinghouse3.fgdc.gov/dougmsg.html

>
   >--
   >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >Allan Doyle adoyle@intl-interfaces.com
   >International Interfaces +1 781 433 2695 (Office)
   >http://www.intl-interfaces.com +1 781 254 9484 (Mobile/Voicemail)