Meeting to be held at CSC, April 19, 2001
Updated: April 19, 2001 17:13 - Page Maintained by Allan Doyle

Present

At CSC
Lou Reich
Doug Nebert
Yonsook Enloe
Allan Doyle
George Percivall
Ananth Rao
William Chen
Jeff de La Beaujardiere

Via Teleconference (sorry about the bad phone connections...)
Arliss Whiteside
Serge Margoulies
Larry Bouzane
David O'Mahony
Ben Burford
Peter Vretanos
Paul Daisey
Juergen Ebbinghaus

Agenda/Minutes

1. Action Item Status

10:15 Actions below were reviewed.

10:20 Note: This discussion is really item 3 of the Catalog agenda below.
Jeff DLB - spoke about his revisions to the DTDs. Got comments back, sent new version of Brief, not sure what to do with Full and Summary. Jeff still needs help with full and summary. Ananth happy with brief. Q: Ideal usage for full/brief/summary.
A: User searches, finds things identified by their title and the title of the provider, can choose one and map it. I.e. the brief would contain enough info to do a GetMap. Or if user wants more info can do a request for Full record to get complete info on just a single layer, or on a few layers. Right now he has to ask for a Full in order to get enough info. Compusult would use Summary where Jeff DLB would use the Brief. We need to capture and agree on the use cases for Brief/Summary/Full.

Detailed and rapid discussion on content of brief_1_2_1.xml

! Human readable title of a layer is not guaranteed to be unique. The <NAME> is the primary key.

Proposal: Layer name, title, service title, and GetCapabilities URL is the minimum for Brief.

Can use XSLT to convert from Full to Brief, Full should contain as much semantics as possible.

New Action: Develop use cases for Brief, Summary and Full. Jeff to write his and Rob's. Compusult to write theirs.
New Action: Given the use cases, decide on the XML content
Pseudo Action: (Extra credit) develop XSLT to pull Summary and Brief from Full...

"provider information" group is a good idea - provides good info to users. Can we reuse the citiation elements for both provider info and object info?

Consensus: Brief should contain only information that's available in the Full. Tag paths need not be preserved. Don't arbitrarily change tag names, though. (Some say don't change tag names at all).

More discussion on use cases. Still more discussion on use cases...

New Action: Jeff DLB will propose a new Brief. As small as possible to be usable.

Proposal: Summary should be smaller than it is now, maybe take over the stuff that will be thrown out of Brief. More info on provider of service, abstract of layer, footprint of layer, no operation metadata.

New Action: Compusult to take Jeff's Full and turn into a Summary.

Arliss suggests that a record carry with it a short description of what the record is for, i.e. could be extracted from use case.

 

2. Catalog/Statless Catalog

The three major topics for the Catalog Services portion of the meeting are:

1. Reuse Web Feature Interfaces in the Stateless Catalog Service/WRS
   specification discussion - Lou Reich

Lou is introducing the topic. See Lou's paper at http://www.intl-interfaces.net/servicemodel/2001.04.18.catcompnote.pdf
Additional observation - GML2 and GML3 may be overkill for a lot of what we want to do.

Lou's Key Point: Attribute Set = things you can query catalog on. Element Set = things you can get back. Z39.50 world allows for these to be disjoint. I.e. the things you can query on (attribute set) are usually at least a subset of the elment set. WFS world says they are the same. I.e. anything that can be returned by a WFS can be queried on.

Key Point: In catalogs, you don't know (or want to know) the schema of the data you are searching for, you search using a generalized set of attributes. This allows you to query catalogs you have not already enountered. This is important for distributed heterogeneous searching.

These two points have to be considered before we can talk about using a WFS interface to implement a Catalog.

GetCapabilities ~ Catalog "Explain server"
DescribeFeatureType ~ Catalog "Explain Schema"

SICAD very interested in the service registry maintenance interfaces (or was it for (data) catalog metadata maintenance?). BAE SYSTEMS is very interested in catalog metadata maintenance interfaces.

Work Plan tasks - "Service Model Issue" - have to understand the Basic Service Model.

Catalog RWG strategy - keep 1.1 "private" and aim for publishing 2.0 to the public.

Back to WFS/Catalog issue: If we use "GetFeature" as a query,do we lose the abstraction of Attributes not being able to be disjoint from the Elements. I.e. does the query language attribute have to be present in the schema. Answer: Right now, yes. GML model is assumed and features have properties. You can only query properties that exist in features.

WFS GetCapabilities provides the list of feature types and the list of operations supported on the feature type. Could extend this to go to the property level.

The issue in all the above is the fact that in a Catalog, the Brief result (for instance) is really a distillation or abstraction of the catalog content (i.e. derived from the Full) whose elements are not actually stored in the catalog.

Another point: Can you do a distributed search if you have no state (i.e. with a stateless catalog). Perhaps the use of the term "Stateless Catalog" is misleading here. When we talk about Stateless Catalog we're really talking about sessionless.

Assertion: In order to be an effective catalog engine, there may have to be changes in the WFS interfaces. Important to separate attributes and entities. Also have to be able to restrict the number of hits.

What would the impact be if we were to "extend" the WFS interfaces to handle the above issues. Peter - they did an exercise to apply WFS style interfaces to the FGDC model. The issue they ran into was the one that Lou identified. WFS is designed to run GML. However the level of abstraction that's needed to do a catalog is doable. Have to add some things to the query interface.

Would be nice to be able to use the query to ask for result metadata - i.e. ask for the count of the records that would be returned. Note - you're not limited to GML for this, can use other XML instead.

If you're going to extend the WFS, you also have to extend GML. Or you have to return a different kind of XML.

WFS can be seen as an implementation of something more abstract that does not depend on GML. I.e. a GML-capable WFS could be a subclass of a set of interfaces that support operations like the current WFS does. Don't restrict ourselves to thinking of WFS as the base class. Think of the WFS as a specialization of a new base class that can also be specialized into a Catalog. This was considered a key point.

Peter says via email: I have a proposal for the name of this THING that we have been talking about that is basically the WFS without GML. My proposed name is: Web Data Management Services (WDMS) The idea being that the specification defines what interfaces should be implemented by a data management service such as the WFS or the WRS. Keep in mind I am talking about an implementation specification here - abstract specs are nice and everything but I am interested in implementations.

Also need to worry about authentication for WFS interfaces (e.g. transactions).

Consensus is that we should work on the interface hierarchy.

Stop overloading the term Feature with things that don't have geographic location.

Action Item: Lou, Peter, Serge - Coordinate OGC Common Query Language SQL version and XML version. Need input from Serge.

Action Item: Lou, Doug - Develop a catalog interface work plan. This is actually item 2 below. Requires an understanding of what's available in something like UDDI.

Action Item: Lou - Initiate a telecon to determine if we need a minimal stateless catalog interface along with a "maximal" one. The current stateless prototypes would be the basis for the minimal, the WFS style interfaces would be the basis of the "maximal" one.

http://ogc.compusult.nf.ca - POST version of the Stateless Catalog.

Remember that we're talking about data catalogs and services catalogs. We should not treat these as separate unless forced to do so. In particular, if we talk about a Service Model, make sure we don't do things that prevent us from using interfaces for data.

 

2. Discussion of a workplan to get to a profile of a BSM based
   Stateless Catalog for OGC Web Services DCP and a full OGC Catalog
   Services 2.0 to meet schedule constraints - Lou Reich/Doug Nebert
3. Discussion of Stateless Catalog result sets - Jeff DLB (see minutes above...)

 

Lou will be sending out material on these topics before 4:00 pm EST
today. If anyone has other topics they would like to discuss please
send material to <catalog.wg@opengis.org> and <servicemodel@opengis.org>

1. Service Model

The topics for the Service Model portion of the meeting are:

1. Flesh out an action plan - i.e. continue what we did in Liege by bringing people up to speed on what we talked about since it was a small meeting
2. Decide how to describe BSM vs. GSM. What we noticed in Liege and in other discussions is that the BSM is not adequate to describe services that are not coupled to data. Even the WFS makes it hard to describe a service in the way we currently do. We have to figure out how to describe services that can be dynamically connected to different data sources.

   Intro to this discussion provided by Allan explaining the Liege meeting slides.

   BSM/GSM described in OGC Web Services RFT. BSM is also a Discussion Paper.

   Doug is talking about a diagram on the white board. Data catalog and UDDI registry instances. The data metadata includes pointers to services that can be found in the UDDI registry. I.e. the data knows what services can be used on it. A more general case is shown in the diagram on the lower right of this picture. In the picture, you can posit a data type list and a service type list and a "matchmaker" service that knows which pairings of data and service type are valid. This is the more general case, and such a matchmaker could be used to generate the list of services that can be tacked onto the data metadata record. Obviously we need use cases.

   Action Item: Develop use cases for BSM/GSM

   Discussion about unbundling the interfaces - problem with calling a WMS a WMS is that it has several interfaces, i.e. rendering, implied feature filter, etc. that we don't think about but should. It's time to tie our thinking back into the 19119 (Topic 12 Services) document. There are things in 19119 about aggregate services and service granularity.

   Think about granularity from the point of view of single interfaces vs. what you would provide as services from a business point of view. Service and operation are terms from 19119. GetFeature would be an operation. Service would be a collection of operations that's useful to a user. Dissenting view holds that individual operations can be useful as services in their own right.

   Classification mechanism that states "if it only fits in one bin in a taxonomy" is good for deciding appropriate granularity.

   Interface vs. operation - Think of a generalized GetFeature that can be reused in multiple services. Operation is uninstantiated, interface is an instantiated, addressable implementation.

   From Peter: This is my impression of how a MAP SERVER LAYER maps to WFS feature types ... A MAP is composed of one or more MAP LAYERS. A MAP LAYER is composed or more constrained feature types. The example I gave is a MAP LAYER called TRANSPORTATION-TORONTO. It could be composed of the features ROADS, RAIL and FOOTPATH all constrained to the region of Toronto. Again this is my impression. I know for example, that we and Ionic map layers 1:1 with feature types which king of does not follow my definition here! Confusion!

   Peter's view is that in a Transaction, sent through a transaction interface, an individual element of the transaction is an operation. E.g. "delete feature" would be an operation that's part of what was sent to a Transaction interface.

   There's still need to define Service, Interface, and Operation.

   Action Item: George Percivall will extract definitions from Topic 12 and send to servicemodel@opengis.org

   Jeff Lansing: Think of the dynamic model as being fundamental to a service. The operations are the trasitions in the state diagram.

   Plan: We have a lot of interlocked tasks with lots of dependencies.

   Action Item: Doug to provide a powerpoint version of his diagram.

   Action Item: Allan and Jeff DLB to think about how to deal with GetCapabilities for bundled interfaces.

   Action Item: Hold open 1000-1200 Telecon Wednesday May 2.

   May 14 = 3 week rule for New Hampshire TC meetings

   Comments on 19119 due to OGC by end of April.

    

    

Action Items