Jody, Jo,<br><br>
<div><span class="gmail_quote">2006/9/25, Jody Garnett <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:jgarnett@refractions.net" target="_blank">jgarnett@refractions.net</a>:</span> </div>
<div>...</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> GeoTools has a Catalog abstraction. This can point to a remote or local<br>> Service. A Service offers an interface through to GeoStuffOfSomeKind.
<br>> This can be an OWS but also an SLD resource or some metadata service.<br>Actuallly the "point to" part is *always* a real resource (ie something that can be shown on a map).</blockquote>
<div> </div>
<div>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?
</div>
<div> <br>...</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> Then you have your own ServiceInfo/GeoResourceInfo internal model<br>> which is a Dublin Core based reduced geometadata subset.
<br>Really we defined it the other way around:<br>1) we want to find stuff to show on the screen<br>2) what is it we want to search when we look for stuff to show on the screen<br>3) now that we have a list, lets steal names from DublinCore
</blockquote>
<div> </div>
<div>This approach sounds reasonable. So, let me make a cross walk again with DC (see below). Perhaps there is some mutual input.<br> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> - How is the local catalog built? From usage? Can it be externalised?<br>> E.g. posted to a remote indexing service? Would this be actually useful?
<br>The local catalog is "just a tool" a programmer can use to manage their connections to geostuff, so<br>they build it via programming. We *do* externalize this for the uDig project (into XML right now), and<br>
we do externalize it for the GeoServer project (into a series of directories with XML files). Setting them<br>up a small database instead would give both projects an excuse to collaborate.</blockquote>
<div> </div>
<div>You mean, one would be able to exchange a sort of dublin core information encoded in XML out of GeoTools?</div>
<div> </div>
<div>
<div>What is the source of information someone in front of uDig get's to know about an remote service? </div>
<div> </div>
<div>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).
</div></div>
<div><br> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> > Also used to go to other interfaces<br>> > - ServiceInfo (for dublin core metadata), morph to any metadata
<br>> > interface you got coded up<br>><br>> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/defaults/DefaultGeoResourceInfo.html" target="_blank">
http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/defaults/DefaultGeoResourceInfo.html </a><br>><br>> Okay this is becoming clearer. What I have been trying to implement on<br>> the server/broker side looks a lot like GeoResource, the OSGeo draft
<br>> metadata model like GeoResourceInfo and what Tom wants for OWSCat more <br>> like ServiceInfo. It is great that you have all this going on the<br>> client side, I want to be able to syndicate it though.<br>
Two sides of the same coin, we just get the fun of making it look easy.<br>> k thanks, <br>> jo<br>Cheers,<br>Jody</blockquote>
<div> </div>
<div>Seems our intentions are converging at this point. Here is my cross walk of GeoResourceInfo and ServiceInfo with DC, respectively with the <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://tinyurl.com/kfkyv" target="_blank">
http://tinyurl.com/kfkyv</a> model. Just to remember: Docu. of GeoResourceInfo says "Much of this interface is based on Dublin Core and the RDF application profile."): </div>
<div> </div>
<div>GeoResourceInfo methods compared to DC: <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/GeoResourceInfo.html " target="_blank">http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/GeoResourceInfo.html
</a></div>
<div> </div>
<div>1. getTitle string // maps to DCs title element<br>2. getKeywords string[] // maps to DCs subject element<br>3. getDescription string // maps to WMS/WFS GetCapabilities <br>4. getSchema URI // xml schema namespace; maps to DCs format
<br>5. getBounds BBox // maps to 1st part of DC coverage element<br>6. getIcon Icon // delivers base symbology of this resource<br>7. getName string // WMS- or WFS layer name or DB name; </div>
<div>
<p>What differs: <br>* shouldn't getSchema be an array (= a GeoResourceInfo has a containment relationhsip to resources)<br>* getBounds rather maps to dct:spatial being a sub-element<br>* 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.
</p>
<p>What makes me wonder: <br>* getIcon I don't understand: A thumbnail?</p>
<p>What's missing from DC Core: <br>* relation (to Services?), language, rights<br>* type: What to do with type? </p>
<p>What's *really* missing from DC Core:<br>* identifier: if in some future this information is to be exchanged, identifier becomes important and perhaps has to be stored in a field.<br>* modified: This is easy to get from geospatial resources.
<br>* publisher: This is in GetCapabilities and really should be there for informations. It's also in ServiceInfo => unintentionally left out by GeoTools?</p>
<p>ServiceInfo methods compared to DC: <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/ServiceInfo.html" target="_blank">http://udig.refractions.net/docs/api-geotools/org/geotools/catalog/ServiceInfo.html
</a></p>
<p>1. getTitle string // returns service title <br>2. getKeywords string[] // maps to DCs subject element<br>3. getDescription string // maps to DCs description?<br>4. getSchema URI // xml schema namespace; maps to DCs format
<br>5. getIcon Icon // delivers base symbology of this resource<br>6. getAbstract string // maps to DCs description (too)?<br>7. getPublisher URI // maps to DCs publisher?<br>8. getSource URI // maps to DCs server element
</p>
<p>What differs: <br>* Similar comments apply like for GeoResourceInfo but now, getPublisher and getSource is there and getName and getBounds is lacking (why?).<br> <br>What makes me wonder: <br>* getDescription: Contains this associations to GeoResources? (you said: Services have a containment relatinship to GeoResources)?
<br>* in DC abstract is a specialization of description. What is the difference here?<br>* getIcon: a thumbnail?<br>* getTitle could map to DCs title element? <br>* getPublisher: map to DCs publisher? <br>* getSource: don't know a DC server element?
</p>
<p>What's missing from DC Core: <br>* relation (to GeoResourceInfo?), language, rights<br>* type and identifier: What to do with it? </p></div>
<div>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?).<br><br>-- Stefan
</div>