SKOS pattern for 'extending' a vocabulary

I’m building RDF/SKOS representations of some well-known ‘codelists’ used in metadata records conforming to the ISO 19115 standard, and profiles derived from that.

Here’s the XML source for the ISO lists: http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml

and here’s my SKOS version: https://www.seegrid.csiro.au/subversion/xmml/ontologies/TBCME/BOM%20Vocabularies/19115-codelists/19115-codelists.ttl

I’ve made each separate list a skos:ConceptScheme.
For example


<http://www.isotc211.org/def/19115/2003/CI_DateTypeCode>

      rdf:type skos:ConceptScheme ;

      rdfs:comment "transformed from the original XML by Simon J D Cox, CSIRO" , "A member of the set of Codelists for description of metadata datasets compliant with ISO/TC 211 19115:2003 and 19139" ;

      rdfs:seeAlso <http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml> ;

      dc:contributor "Simon J D Cox" ;

      dc:creator "ISO/TC 211" ;

      dc:description "identification of when a given event occurred" ;

      dc:source <urn:iso:std:iso:19115> ;

      dct:created "2005-03-18" ;

      dct:modified "2011-08-24" ;

      skos:definition "identification of when a given event occurred" ;

      skos:prefLabel "CI_DateTypeCode" .



<http://www.isotc211.org/def/19115/2003/CI_DateTypeCode#creation>

      rdf:type skos:Concept ;

      dc:description "date identifies when the resource was brought into existence" ;

      skos:definition "date identifies when the resource was brought into existence" ;

      skos:inScheme meta:CI_DateTypeCode ;

      skos:prefLabel "creation" .

etc.

The WMO (World Meteorological Organization) re-uses these lists, but in some cases adds some additional entries.
I’ve modelled the extended lists as new ConceptSchemes: see https://www.seegrid.csiro.au/subversion/xmml/ontologies/TBCME/BOM%20Vocabularies/WMO-codelists/WMO-codes.ttl

How to import the entries from the ISO lists into the WMO lists?
So far I’ve simply asserted that the new list skos:hasTopConcept  every Concept from the original list.
From this it can be inferred that the imported Concept is also skos:inScheme the extended scheme.
For example

<http://wmo.int/wis/2010/metadata/def/CI_DateTypeCode>
      rdf:type skos:ConceptScheme ;
      rdfs:comment "Extension of ISO codelist"@en ;
      rdfs:label "CI_DateTypeCode"@en ;
      rdfs:seeAlso <http://www.isotc211.org/def/19115/2003/CI_DateTypeCode> ;
      dc:title "CI_DateTypeCode"@en ;
      skos:hasTopConcept <http://www.isotc211.org/def/19115/2003/CI_DateTypeCode#revision> , <http://www.isotc211.org/def/19115/2003/CI_DateTypeCode#creation> , <http://wmo.int/wis/2010/metadata/def/CI_DateTypeCode#reference> , <http://www.isotc211.org/def/19115/2003/CI_DateTypeCode#publication> ;
      skos:prefLabel "CI_DateTypeCode"@en .

and then adds one new element


<http://wmo.int/wis/2010/metadata/def/CI_DateTypeCode#reference>

      rdf:type skos:Concept ;

      rdfs:label "reference"@en ;

      skos:definition "date identifies when the resource was referenced or accessed"@en ;

      skos:inScheme wmo:CI_DateTypeCode ;

      skos:notation "004"^^xsd:string ;

      skos:prefLabel "reference"@en .

This works, but doesn’t feel quite right because it is tedious and probably not scalable to add the original member concepts one by one.
Furthermore, the only hint that the imported concepts all belong to a single external scheme is in the URI.
Is there a better pattern?

Simon Cox