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

Stefan F. Keller sfkeller at gmail.com
Mon Sep 25 18:53:15 EDT 2006


Jody,

Thanks for the comments and the intro to GeoTools API...

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

> Stefan F. Keller wrote:

...

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


That is exactly I am looking firstly: a simple spec. to implement such a
'discovery portal'. Can you recommend one of the above mentioned services
(if there is a protocol spec.)?

Secondly I'm looking for a common minimal metadata model to help users to
decide and finally move on (here we have a chicken-and-egg problem: no
tools, no usage experience of metadata and: no model based on metadata entry
experience, no tools?)


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


 Do we have here a chicken-and-egg problem too? Show me an halfway
functioning simple protocol then I have choice.


> have a mad metadata plan around somewhere about writing "adapters" from
> the various metadata flavours to the above cited "dublin core lite", but


"dublin core lite"? (I coined the term ISO 19115 Core lite...) Any reference
to this? Any affinity to the http://tinyurl.com/kfkyv model I just revised
based on your input?
...

> * modified: This is easy to get from geospatial resources

>
> Not sure this would matter to a client application?


To me this matters mostly a user to rank two similar data sets.


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


How? Through which element?

Does getDescription returns just the URL or rather the whole response string
from OWS GetCapabilities?

> ServiceInfo methods compared to DC:

...


> > * getDescription: Contains this associations to GeoResources? (you
> > said: Services have a containment relatinship to GeoResources)?
> >
> see super class members() method...
>
When speaking of members: There would be also sets/collections of metadata
records modeled by DC. But let's leave this out for now :->

> > * in DC abstract is a specialization of description. What is the
> > difference here?
> >
> In java "abstract" is a reserved word :-)
>
There are fields _abstract and description. Why?


> > What's missing from DC Core:
> > * relation (to GeoResourceInfo?), language, rights
> >
> relatinship is covered, language and rights are of interest.


Just checked with DC again. What you call getSource could be some subtype of
relation (e.g. cld:isAccessedVia). dc:source as I understand DC is reserved
to lineage.

This holds also for GeoResources: Currently there is an element/field
lacking when someone wants to enter something like
ftp://host.com/path/filename. cld:isAccessedVia could be an element of
choice.

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


Don't understand this type definition (except Grid). DC says it's "The
nature or genre of the content of the resource (text, image, sound)". I
propose mainly the enum values: 'data access service' and geodata or more
detailed: vector, raster, grid?

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


More information about the Geodata mailing list