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

[Stefan F. Keller]

Jody, Jo,

2006/9/25, Jody Garnett jgarnett at refractions.net:
...

> > GeoTools has a Catalog abstraction. This can point to a remote or local
> > Service. A Service offers an interface through to GeoStuffOfSomeKind.
> > This can be an OWS but also an SLD resource or some metadata service.
> Actuallly the "point to" part is *always* a real resource (ie something
> that can be shown on a map).


This is a nice idea I always supported. In fact ArcCatalog and
ESRI's geography network had such a functionality since some time as I know
(sorry folks, this is just an free but prorietary example). Do we want to
make something different from a conceptual point of view?

...

> > Then you have your own ServiceInfo/GeoResourceInfo internal model
> > which is a Dublin Core based reduced geometadata subset.
> Really we defined it the other way around:
> 1) we want to find stuff to show on the screen
> 2) what is it we want to search when we look for stuff to show on the
> screen
> 3) now that we have a list, lets steal names from DublinCore


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?

 What is the source of information someone in front of uDig get's to know
about an remote service?

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. 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).



> > > 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
>
> >
> > 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.
> > k thanks,
> > jo
> Cheers,
> Jody


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."):

GeoResourceInfo methods compared to DC:
http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/GeoResourceInfo.html


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)
* getBounds rather maps to dct:spatial being a sub-element
* 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.

What makes me wonder:
* getIcon I don't understand: A thumbnail?

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.
* modified: This is easy to get from geospatial resources.
* publisher: This is in GetCapabilities and really should be there for
informations. It's also in ServiceInfo => unintentionally left out by
GeoTools?

ServiceInfo methods compared to DC:
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?).

What makes me wonder:
* getDescription: Contains this associations to GeoResources? (you said:
Services have a containment relatinship to GeoResources)?
* in DC abstract is a specialization of description. What is the difference
here?
* 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
* type and identifier: What to do with it?
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?).

-- Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geodata/attachments/20060925/dfa733cd/attachment.html