GSIP 64 Keyword Vocabularies and Languages

GSIP 64 - Keyword Vocabularies and Languages

Overview

Supporting vocabulary and language attributes for keywords with OGC services.

Proposed By

Justin Deoliveira

Assigned to Release

2.1.x, trunk

State

Under Discussion, In Progress, Completed, Rejected, Deferred

Motivation

Many OGC services allow keywords to contain additional attributes. WMS 1.3 allows a keyword to have a vocabulary. The OWS schema allows for a keyword to specify a language. This proposal expands on current GeoServer keyword support in support of this.

Proposal

For the quick version see the current patch

Currently keywords are implemented as a single string. For instance consider the ServiceInfo interface:

interface ServiceInfo {
    ...

    /**
     * Keywords associated with the service.
     * 
     * @uml.property name="keywords"
     */
    List<String> getKeywords();

    ...
}

Similarly so does ResourceInfo. The idea is to change this from a string to a domain object named KeywordInfo that can model the additional information:

interface KeywordInfo {
    /** the keyword value */
    String getValue();

    /** the language of the keyword, or null if none set */
    String getLanguage();

    /** the vocabulary of the keyword, or null if none set */
    String getVocabulary();
}

The ServiceInfo and ResourceInfo interfaces/classes will be changed to contain list of KeywordInfo rather than list of String. See [#backwardscompatibility] for details on how this affects the serialized representation.

The keyword editor is extended to allow for setting language and vocabulary from the UI.

And the capabilities transformers are updated to output the values.

<Service>
  <Name>WMS</Name>
  ...
  <KeywordList>
   <Keyword vocabulary="something">foo</Keyword>
   <Keyword vocabulary="somethingElse">bar</Keyword>
   <Keyword vocabulary="">baz</Keyword>
  </KeywordList>
  ...

Feedback

Backwards Compatibility

Changing the keyword class leads to a different representation produced by xstream and hence changes the data directory format. However, with some XStream trickery this can be done in a 100% backward compatible way. Currently keyword persistence looks like the following:

  ...
 <keywords>
   <string>foo</string>
   <string>bar</string>
 </keywords>
  ...

The idea is to serialize KeywordInfo (via a custom XStreamPersister binding) as a simple string of the format:

<keyword>[@language=<language>;][@vocabulary=<vocabulary>]

As an example:

  ...
 <keywords>
   <string>foo@language=en;@vocabulary=something;</string>
   <string>bar@language=it;</string>
   <string>baz@vocabulary=somethingElse;</string>
 </keywords>
  ...

In this way we don’t change the structure of the serialized format, and hence don’t introduce any data directory incompatibilities. There is however the forward compatibile issue that if someone adds keywords (with one of the new attributes) with a new version, saves them, and then reverts to an older geoserver the keyword strings will contain the full serialized versions.

Voting

Andrea Aime: +1 Alessio Fabiani: Ben Caradoc Davies: Gabriel Roldan: +1 Justin Deoliveira: +1 Jody Garnett: +1 Mark Leslie: Simone Giannecchini:

Links

JIRA Task Email Discussion Wiki Page