[Fwd: Re: [OSGeodata] Re: [Geotools-devel] On the catalog tutorial]

[Jody Garnett]

Stefan F. Keller wrote:
> This approach sounds reasonable. So, let me make a cross walk again 
> with DC (see below). Perhaps there is some mutual input.
>  
>
>     > - How is the local catalog built? From usage? Can it be
>     externalised?
>     >   E.g. posted to a remote indexing service? Would this be
>     actually useful?
>     The local catalog is "just a tool" a programmer can use to manage
>     their connections to geostuff, so
>     they build it via programming. We *do* externalize this for the
>     uDig project (into XML right now), and
>     we do externalize it for the GeoServer project (into a series of
>     directories with XML files). Setting them
>     up a small database instead would give both projects an excuse to
>     collaborate.
>
>  
> You mean, one would be able to exchange a sort of dublin core 
> information encoded in XML out of GeoTools?
One could do that, the above comments were more about offering an 
application writer a way to persist their knowledge of external resources.
> What is the source of information someone in front of uDig get's to 
> know about an remote service?
Currently it is the information a catalog chooses to serve up to us, or 
from the capabilities document of a remote service. Or header 
information from shapefile, or table metadata from database etc...  
> Google has a programmatic interface. I can't imagine that every 
> desktop GIS or GeoServer will contain a crawler which constantly looks 
> for new services or geospatial resources.
Um, the point of this API is that we have multiple implementations 
available as plugins, one that works against the geoconnections 
discovery portal, one that works against Paul Ramsey's database of Open 
Web Services, and hopefully one build against the end result from this 
mailing list.
> So, what about more clever GIS related services which serve as 
> brokers? What about moving this GeoResourceInfo and ServiceInfo data 
> around? To me this sounds like we need a metadata exchange protocol. 
> The most import thing though which is lacking, is an information 
> model... (see crosswalk below).
As a client application (and library) we cannot be selective, we need to 
work with what ever information is made available.

In terms of a metadata exchange model, I always view such efforts as 
doomed - you need to exchange all metadata in, a non lossy manner. I 
have a mad metadata plan around somewhere about writing "adapters" from 
the various metadata flavours to the above cited "dublin core lite", but 
the central goal is to preserve metadata for applications that actually 
do understand it.  
>
>     > > Also used to go to other interfaces
>     > > - ServiceInfo (for dublin core metadata), morph to any metadata
>     > > interface you got coded up
>     >
>     >
>     http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/defaults/DefaultGeoResourceInfo.html
>     <http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/defaults/DefaultGeoResourceInfo.html>
>     >
>     > Okay this is becoming clearer. What I have been trying to
>     implement on
>     > the server/broker side looks a lot like GeoResource, the OSGeo
>     draft
>     > metadata model like GeoResourceInfo and what Tom wants for
>     OWSCat more
>     > like ServiceInfo. It is great that you have all this going on the
>     > client side, I want to be able to syndicate it though.
>     Two sides of the same coin, we just get the fun of making it look
>     easy.
>
> Seems our intentions are converging at this point. Here is my cross 
> walk of GeoResourceInfo and ServiceInfo with DC, respectively with the 
> http://tinyurl.com/kfkyv model. Just to remember: Docu. of 
> GeoResourceInfo says "Much of this interface is based on Dublin Core 
> and the RDF application profile."):
We are also open to modification and suggestion.
> GeoResourceInfo methods compared to DC: 
> http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/GeoResourceInfo.html 
> <http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/GeoResourceInfo.html%20>
This contains informaiton about spatial information (ie ISO19115 level 
information about spatial data)
>  
> 1. getTitle       string   // maps to DCs title element
> 2. getKeywords    string[] // maps to DCs subject element
> 3. getDescription string   // maps to WMS/WFS GetCapabilities
> 4. getSchema      URI      // xml schema namespace; maps to DCs format
> 5. getBounds      BBox     // maps to 1st part of DC coverage element
> 6. getIcon        Icon     // delivers base symbology of this resource
> 7. getName        string   // WMS- or WFS layer name or DB name;
>
> What differs:
> * shouldn't getSchema be an array (= a GeoResourceInfo has a 
> containment relationhsip to resources)
>
There is a superclass that has a getMembers method, however IService 
represents a service endpoint, that contains GeoResources. Note 
GeoResources can have internal contents (as in the WMS Layer containing 
layer's case).
>
> * getBounds rather maps to dct:spatial being a sub-element
>
not sure about that, our bounds contains a bounding box w/ CRS if that 
was not clear?
>
> * getName seems to me something rather internal or only for decoration 
> (Layer names as short titles?); and ServiceInfo has it neither. To me 
> it's redundant to getTitle.
>
Often a service makes use of a "real" for a resource (example "name" is 
used for making get map layer requests, and a title that is all done up 
with international support for different langagues)
>
> What makes me wonder:
> * getIcon I don't understand: A thumbnail?
>
Indeed, one of the things available from a WMS, and one of the things 
needed to visually convey the feature type of a referenced collection etc...
>
> What's missing from DC Core:
> * relation (to Services?), language, rights
> * type: What to do with type? 
>
> What's *really* missing from DC Core:
> * identifier: if in some future this information is to be exchanged, 
> identifier becomes important and perhaps has to be stored in a field.
>
This is in the superclass, as getId(): URI
>
> * modified: This is easy to get from geospatial resources.
>
Not sure this would matter to a client application?
>
> * publisher: This is in GetCapabilities and really should be there for 
> informations. It's also in ServiceInfo => unintentionally left out by 
> GeoTools?
>
This was not often used by users doing a search, the focus is on the 
content not the accountability. They can look at these details when they 
decide they want to know more.
>
> ServiceInfo methods compared to DC: 
> http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/ServiceInfo.html 
> <http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/ServiceInfo.html>
>
> 1. getTitle       string   // returns service title
> 2. getKeywords    string[] // maps to DCs subject element
> 3. getDescription string   // maps to DCs description?
> 4. getSchema      URI      // xml schema namespace; maps to DCs format
> 5. getIcon        Icon     // delivers base symbology of this resource
> 6. getAbstract    string   // maps to DCs description (too)?
> 7. getPublisher   URI      // maps to DCs publisher?
> 8. getSource      URI      // maps to DCs server element
>
> What differs:
> * Similar comments apply like for GeoResourceInfo but now, 
> getPublisher and getSource is there and getName and getBounds is 
> lacking (why?).
>
Hope the separation is now clear, this represents a web service - (ie 
ISO19119 style information)
>
> What makes me wonder:
> * getDescription: Contains this associations to GeoResources? (you 
> said: Services have a containment relatinship to GeoResources)?
>
see super class members() method...
>
> * in DC abstract is a specialization of description. What is the 
> difference here?
>
In java "abstract" is a reserved word :-)
>
> * getIcon: a thumbnail?
> * getTitle could map to DCs title element?
> * getPublisher: map to DCs publisher?
> * getSource: don't know a DC server element?
>
> What's missing from DC Core:
> * relation (to GeoResourceInfo?), language, rights
>
relatinship is covered, language and rights are of interest.
>
> * type and identifier: What to do with it?
>
super class getId(): URI covers identifier. Type (and what to do with 
it) is covered by query, resolve( GridCoverage.class ) etc...
>
> To summarize: Fun to compare. The most important question to me are, 
> why getSchema in GeoResourceInfo is not an array and from how 
> ServiceInfo get's the associations to GeoResources (getDescription?).
Service.members() has the association to GeoResource, ServiceInfo is 
just describing one thing (the service). Need to remember these "are" 
handles to real information (literally catalog records when returned 
from geoconnection discovery portal).

Cheers
Jody