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

Jody Garnett jgarnett at refractions.net
Mon Sep 25 22:10:00 EDT 2006


Stefan F. Keller wrote:
> 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?)
peep! (lets start with the chicken) uDig catalog represents a tool - 
that is actively interested in your service.

I am fond of iterative development ...
step one) get the data (just let people find published data)
step two) get the associations (recognize if the same data appears on 
both a WMS and WFS, even just using pattern matching)
step three) work on the associations (catalog styles by feature type, 
organize feature types into an ontology)

We also have some hard experience based out on OWS-3 involvement that we 
can share with you (heck if we attended an OGC meeting
we get our interoperability report published so you could read about it)....

So what do we have ...
a) no tools - well we are hackers we build tools, we have a client 
codebase in uDig ...
b) no usage experience of metadata - well once again uDig has experience
c) no model based on metadata entry experience - this one is tough! We 
have Paul saying the metadata will not be entered, I would take the 
point of view we need a strong motivator for any meta data to be 
collected  ...
d) no tools - GeoNetwork does offer metadata entry ...

(crack) returning to the egg.

No tools actually represents a point of advantage for us, if we figure 
out information we are happy with and provide some tooling for it we can 
step into a current void. This applies to a client api like 
geotools/udig - and it applies for a service.
>
>     > 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.
Thinking, wondering if we are talking about the same thing here or not? 
I am not worried about exchange of information between systems, I am 
worried about:
a) providing an interface (java) that provides a consistent set of 
information for searching against
b) wraps around existing information (capabilities document, search 
result, ISO19115, etc...)
c) preserves the original (so others can write different wrappers, or 
make use of the original content if they choose)

So even if I *was* to transfer this information to another system, I 
would rather transfer the original source material.

It seems to me that you would like a single "lowest common denominator" 
to use for interchange between catalog services?
(Something like the CSW 2.0 "brief" idea, rather then full on crazy 
ISO19115/19119?)

>     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?
Sorry I was searching for your term :-)

> ...
>
>  
>
>     > * 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?
 By contacting the service and having a look at say the capabilities 
document for the OWS for example. The information you list
here is important, it just did not make our "shortlist" for the uDig 
application.
> Does getDescription returns just the URL or rather the whole response 
> string from OWS GetCapabilities?
It returns the "abstract" from the GetCapabilities document.
>
>     > * 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 :->

We saw the multiplicity and stepped back ourselves, did not meet our 
needs for simplicity.
>
>     > * 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?
Well you caught me out, I will have to go look :-)
> 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.
Interesting, you are correct that our "parent" relationship is based on 
containment (or aggregation) rather then 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.
>
>     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?
Sorry our "handle" concept includes two methods:
- canResolve( GridCoverage.class ) - returns true or false
- resolve( GridCoverage.class )

Consider this "query" by prototype if we must.  Based on your enums we 
can answer the "canResolve" question - which is all we need to do.

Cheers,
Jody




More information about the Geodata mailing list