Opened 13 years ago
Last modified 12 years ago
#691 reopened enhancement
Keyword selection / add keyword using gmx:Anchor instead of gco:CharacterString
Reported by: | fxp | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | v2.8.0 |
Component: | General | Version: | v2.8.0RC1 |
Keywords: | Cc: |
Description
In some metadata profiles, keywords are created using gmx:Anchor instead of gco:CharacterString. It needs basic support for Anchor (See #681) and changes on KeywordBean#getComplexIso19139Elt which is called before adding keywords.
Example:
<gmd:descriptiveKeywords> <gmd:MD_Keywords> <gmd:keyword> <gmx:Anchor xlink:href="http://www.seadatanet.org/urnurl/SDN:P021::ATVS">Atmospheric visibility and transparency</gmx:Anchor> </gmd:keyword> <gmd:keyword> <gmx:Anchor xlink:href="http://www.seadatanet.org/urnurl/SDN:P021::SAGE">Sediment age</gmx:Anchor> </gmd:keyword> <gmd:type> <gmd:MD_KeywordTypeCode codeList="http://www.seadatanet.org/urnurl/codelists.xml#MD_KeywordTypeCode" codeListValue="parameter" codeSpace="http://www.seadatanet.org/urnurl/">parameter</gmd:MD_KeywordTypeCode> </gmd:type> <gmd:thesaurusName> <gmd:CI_Citation> <gmd:title> <gco:CharacterString>BODC Parameter Discovery Vocabulary</gco:CharacterString> </gmd:title> <gmd:alternateTitle> <gco:CharacterString>P021</gco:CharacterString> </gmd:alternateTitle> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2009-06-05</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="revision" codeSpace="ISOTC211/19115">revision</gmd:CI_DateTypeCode> </gmd:dateType> </gmd:CI_Date> </gmd:date> <gmd:edition> <gco:CharacterString>41</gco:CharacterString> </gmd:edition> <gmd:identifier> <gmd:MD_Identifier> <gmd:code> <gco:CharacterString>http://www.seadatanet.org/urnurl/SDN:P021</gco:CharacterString> </gmd:code> </gmd:MD_Identifier> </gmd:identifier> </gmd:CI_Citation> </gmd:thesaurusName> </gmd:MD_Keywords> </gmd:descriptiveKeywords>
Change History (10)
comment:1 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 12 years ago
Milestone: | Future release → v2.7.0 |
---|
comment:3 by , 12 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Version: | → v2.8.0RC1 |
Keywords selection in the advanced GUI, in the editor, leads to create keywords using gmx:Anchor... Is it an expected behavior in 2.8.0-RC1?
I'm wondering how gmx:Anchor elements are supported in that version because it breaks search on keywords (i.e. computing extent from keywords). Thanks in advance for your reply
comment:4 by , 12 years ago
I think the idea behind this is that if you going to select a keyword from the thesaurus then you need to be able to recover the exact keyword from the thesaurus - to do this you need the id of that keyword in the thesaurus otherwise you can't really know which one it is (reliably that is) - to do that you would need a gmx:Anchor (or some other substitute) rather than a gco:CharacterString. In what way does it break the computing extent from keywords process (apart from the obviously allowing for both gco:CharacterString and gmx:Anchor)? Just looking at the process xslt I can't see that it would be difficult to make it work with either?
comment:5 by , 12 years ago
I think that should be a profile configuration. I'm working on a proposal for that which extends the ideas described in the registers proposal by providing a way to use a thesaurus selection for making any ISO elements by defining:
- association: eg. thesaurus A could be used to define ISO element of type gmd:descriptiveKeywords (but could be other like gmd:extent)
- transformation: eg. gmd:descriptiveKeywords could be added as XLinks, gco:CharacterString, gmx:Anchor
The configuration could be made on a per profile basis and the type of transformation will be available as a choice in the thesaurus selection popup (instead of having the xlink or not only option as currently).
The configuration would look like this:
<!-- All thesaurus for gmd:descriptiveKeywords --> <registerAssociation registerId="local://thesaurus/*" element="gmd:descriptiveKeywords"/> <!-- 3 conversions from SKOS to ISO --> <!-- Add keyword as ISO19139 fragments --> <registerTransformation element="gmd:descriptiveKeywords" xslTpl='skos2gmd_keywords'/> <!-- Add keyword as ISO19139 fragments using gmx:Anchor --> <registerTransformation element="gmd:descriptiveKeywords" xslTpl='skos2gmd_keywords_with_anchor'/> <!-- Add keyword using an Xlink --> <registerTransformation element="gmd:descriptiveKeywords" xslTpl='skos2gmd_keywords_with_xlink'/>
I'll write a draft proposal on it this month probably.
For 2.8.x, it's maybe better to keep gco:CharacterString by default ? as gmx:Anchor is probably not so well known for the general user.
comment:6 by , 12 years ago
Yep Simon and François, I fully understand the need or the use of the gmx:Anchor for keywords but my concern is more focused on coming 2.8 version where defaults gmx:Anchor elements break the computing extent from keywords process. Can we update the process stylesheet to support default gmx:Anchor or maybe can we set back gco:CharacterString as default element when creating keywords for the 2.8.x branch? Any thoughts...
comment:7 by , 12 years ago
I'll happily update the process stylesheet to handle both (don't think this is a big task). Also, for the time being (until we get a per profile config as described above) maybe we could config this as a global option - default is the kind of stupid old gco:Char thing but if config is set then Anchors are used. Certainly critical for Anchors to be supported for use cases here where we sometimes have > 10 thesauri in use....
comment:8 by , 12 years ago
Milestone: | v2.7.0 → v2.8.0 RC2 |
---|
comment:9 by , 12 years ago
Milestone: | v2.8.0 RC2 → v2.8.0 |
---|
comment:10 by , 12 years ago
Here is a mechanism which could handle CharacterString, Anchor and XLink addition mode using a widget in the editor instead of the popup. See http://www.youtube.com/watch?v=prSRnnUmyDA
Feedback welcomed.
This change could be added to 2.9.x I think.
Fixed in commit #9241