OWS Metadata Matters

This has seemingly been the theme for me in the last few weeks.  From publishing to discovery, lack of metadata in OWS endpoints results in increased metadata management away from source, as well as crappy search results.

So here’s some friendly advice:

Service Metadata

  • fill out title, abstract (representative of the OWS as a whole) with descriptive metadata
  • fill out keywords to categorize the service.  If possible, use a known thesaurus, or one specific to your organization.  Don’t use keywords like “OGC”; we already know it’s an OGC service from the get-go by interacting with it
  • fill out contact information.  OWS Common defines ServiceProvider metadata constructs, so if your organization has a service provider dishing out your OWS, they belong in this metadata.  This is a contact person for the service itself, not the data
  • fill out Fees and AccessConstraints.  If there aren’t any, use the term “None”
  • the OnlineResource for Service Metadata might be some website, not the URL of the service itself (we already get this from the OperationsMetadata)

Content Metadata

  • fill in title, abstract and keywords in the same manner as above, specific to the given Layer/FeatureType/Coverage/ObservationOffering.  A title like “ROAD_1M” doesn’t cut it
  • your data comes with an FGDC or ISO 19115 XML document already, right?  :) Use MetadataURL to point to the XML document.  Smart catalogues will harvest this too and associate it with the resource
  • WMS DataURL: if the data can be downloaded online (tgz/zip/etc.), point to it here.  Or, put a pointer to an access service like WFS/WCS/SOS
  • WMS Layer Attribution: this provides reference to the content provider (URL, title and LogoURL).  Filling in LogoURL is neat as catalogues can display this when users search for content.  If possible, use an image of smaller dimensions so as to display as a thumbnail
  • Last but not least, bounding boxes.  Whether your OWS software automagically calculates these per layer on the fly, or you can override these and set before runtime, please set spatial extents accordingly.  This improves searching spatially by leaps and bounds.  Don’t settle for the often used default of -180, -90, 180, 90 unless it is really a global dataset

From here, OGC Catalogues will be able to harvest your metadata and provide useful search results.  For wider spread discovery, throw an OpenSearch definition in front of your CSW.  Wrap your OWS endpoints in KML/GeoRSS documents (Geo Sitemaps too), and you’ll power mainstream use of your stuff.

Bye bye useless searches!

4 Comments so far »

  1. sophia said,

    Wrote on February 5, 2009 @ 19:33:04

    Mozilla Firefox 3.0.6 Mac OS X 10

    things never change: http://weblogs.java.net/blog/jive/archive/2005/10/making_up_for_1.html

    Posted from United States United States
    Mozilla Firefox 3.0.6 Mac OS X 10
  2. Jody Garnett said,

    Wrote on February 6, 2009 @ 00:28:44

    Google Chrome 1.0.154.43 Windows Vista

    A very good point :-) If I can recommend writing up a “before” and “after” example to illustrate the difference your advice makes :-)

    Now here is the trick question; a lot of the poorly titled “Road_1M” examples comes out of help applications like GeoServer that try and fill in a nice default value – so people can work with their data sooner. What kind of balance can we strike between ease of use and and asking users to be descriptive?

    Posted from Australia Australia
    Google Chrome 1.0.154.43 Windows Vista
  3. tomkralidis said,

    Wrote on February 8, 2009 @ 19:22:26

    Mozilla Firefox 3.0.6 Mac OS X 10

    For example, check out the EMAN WMS. Copious metadata. In the sense of OGC Catalogues, searching for “frogs” or “toads” will return their FrogWatch layer given their metadata. If they had no title/abstract/keywords, and their layer was simply named “FrogWatch”, there would be no results (well, in a simple PropertyIsEqualTo kind of way).

    I realize, though, that the above example doesn’t make for a sexy story to make people jump at their metadata editors :)

    One thing that we can do is more front end tools for OWS software setup/config/admin (I like GeoServer’s admin panel for this) in the form of helpers. Have a status check for title/abstract/keywords (red X’s if they aren’t filled out, warnings if they are extremely short). Have links to existing thesauri for keyword population if the user has none. Preprocessing MBRs for layer extents. That sort of thing.

    Perhaps a GeoServer plugin for “OWS pedantic” mode :)

    Posted from Canada Canada
    Mozilla Firefox 3.0.6 Mac OS X 10
  4. tomkralidis said,

    Wrote on February 9, 2009 @ 19:34:14

    Mozilla Firefox 3.0.6 Mac OS X 10

    Another Layer Metadata suggestion: if your data is scale dependent, set MinScaleDenominator and MaxScaleDenominator accordingly. This enables searching by scale, as well as smart clients being able to call your scale-dependent layer only when they are in range.

    Posted from Canada Canada
    Mozilla Firefox 3.0.6 Mac OS X 10

Comment RSS · TrackBack URI

Leave a Comment

Name: (Required)

E-mail: (Required)

Website:

Comment:

Modified: 5 February 2009 23:13:46 EST