> 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).
...
> 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
> - 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.
> > 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
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?
-- Stefan
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
