Draft WMO Core Metadata Profile specification document for review

[Jeremy]

All, please find attached a first rehash of the WMO Core Metadata Profile documentation as a formal specification.

The document is incomplete; you'll see many 'review comments' still to be resolved ... some of them require input from IPET-MDI team!

Also note that I am yet to write the Abstract Test Suite.

I think that it's going to be a few days (no sooner than Tuesday) until I can return to this document (at which point I will start working on release 0.2) so there's plenty of time for you to provide comment and feedback.

Jeremy

[Steve Foreman]

Jeremy,

Comments on the draft.

Overall - well done!

Typographically, - full justification gets silly with the long names in the text - we'll go for left justification - I hope you have used consistent Word Styles!

I prefer "requires that" to "mandates" throughout the document. Those less familiar with English may not be clear on the different meanings of "mandate".

Comment J1 - Given that we decided to allow xlinks, putting them in as a normative reference at least means that if people do use them, they are told how to do so!

Comment J2 - If we don't use our own namespace, leave it out.

Page 7 - paragraph immediately below 8.1.2> should be "i.e." instead of "e.g."

Page 8 under unique identifier - first bullet point: "for metadata records describing GTS products in bulletins or in files named ......."  (because we will have bulletins for some time to come, and not all these are exchanged as files.)

Page 9 - I think this is a Word 2007 to 2003 problem - there is different line spacing between the first two elements in the list than between the others.

Page 11 - comment J7 - Making the point of contact Mandatory helps with the maintenance of the metadata records. However, it does cause problems for data imported from other centres. However, I suggest we do make it mandatory because of the need to be able to trace back metadata records to their owners.

Page 12 - top paragraph. "In order to ...... DAR Catalogue, the keyword attribute is mandatory and the boundingBox attribute is conditional within the WMO Core Metadata Profile.

Page 12 - Comment J9 - the issue is not how to describe boxes crossing the date line, it is whether software interprets them correctly. With the range +/- 180 for lat and long, any box crossing the dateline will have West > East in the bounding box definition (won't it?) At least, but the natural definition of the limits.

When it comes to bounding boxes crossing the pole we do have a problem - the eastern-most limit on one side of the pole becomes the western-most limit on the other! However, we have defined bounding boxes to be aligned along lines of latitude and longitude, so I think we say that for boxes spanning the pole, one of the latitude constraints should be the pole, and the east and west limits should be West -180, East 180. But that could be in the guidance!

Page 12, comment J10 - if they are optional, leave them to the guidance.

Page 11 - comment J13. I will set up sub-pages for these direct links "WmoMdTopicTopicName" (for this one Table2Elements for TopicName)

Page 13 - Are we going to follow ISO 19115-1 and call it dataCentre (the DIS document still has dataCenter) - Ted's call.

Page 14 section 9.2 repeats para 8.1, page 8. I suggest we remove 9.2, and add the examples to 8.1 - commenting in 9.2 that the method defined in 8.1 must be followed.

Page 14  comment 12 - Yes - we can make it mandatory - we just have to introduce different keywords if we want to say "not worthy of being on GTS"!

p15 - remove spaces "WMOAdditional" etc.

p15 - spell out aka in full

Page 15 - URL ending in DataPolicies?

p16 - comment J16 - Yes - that is what I thought we had agreed. Can it go in with the code tables? If so, wis.wmo.int/2011/codetables/giscs.???

p16 - Comment J20 - what formal should the list of URLs be provided in? That determines the file extension of the URL!

p17 comment J21 URL ending in DigTranOpt?

p18 - table entry 2 - delete 8.2.4 (copied to box below already)

p20 - remove top copy of figure one (my copy of the document has two identical copies of the diagram)

p22 (Figure 2) - given than Bounding Box is now conditional, should EX_Extent be 0..*  (instead of 1..*) ?

p30 - row 343 - should be type Conditional (not Mandatory?)

p32 - row labelled 117 should be labelled 390 (onlineResource)

p34 - comment J23 - location of code lists - wis.wmo.int/2012/codelists (alongside any schemas that we define - none this year!)

p35 - row 7 of table 17 - DataCenter - keyword identifiers a repository of archive that manages and distributes data

p3 - comment J26 - ought to refer to web page on wiki that then links to the source of the validation  (I think we should store the reference copy of the schematron etc in wis/wmo.int/2012/validate)?

I can edit these into Jeremy's draft to leave you all time to work on the validation. I will also have a go at updating the code lists - I have a version updated to the start of the meeting, so I "only" need to add in the changes from the meeting.

Steve

[Ted Habermann]

Jeremy et al.,

Took a first shot at this on the plane...

Not sure I like the single URL approach to distribution URLs... How many GISCs are there and how often does that number change?

Ted

[Jeremy Tandy]

Ted - am happy to introduce alternatives; there will potentially be about a dozen GISCs. Over the next couple of years we expect new GISCs to 'come on-line' periodically then things to settle down somewhat. 

Steve et al. Your thoughts to Ted's questions?

Jeremy

==== Ted Habermann ===========================
  We have been told we cannot do this by a chorus of cynics...
  they will only grow louder and more dissonant .
  We've been asked to pause for a reality check.
  We've been warned against offering the people
  of this nation false hope.
  But in the unlikely story that is America, there has
  never been anything false about hope.
  Barack Obama
==== rehab...@me.com ==================

[Jeremy Tandy]

Steve - thanks for the comment and review.

One question:

>>>

Page 11 - comment J7 - Making the point of contact Mandatory helps with the maintenance of the metadata records. However, it does cause problems for data imported from other centres. However, I suggest we do make it mandatory because of the need to be able to trace back metadata records to their owners.

<<<

The metadata ownership _IS_ already mandatory. PointOfContact in this context refers to the _DATA_

Very happy for you to merge these changes in (TrackChanges please!) & to update the codelists. :-)

Jeremy

[Steve Foreman]

Jeremy, Ted

changes already made - will upload to the ISS meeting page.

Thanks for the clarification on pointOfContact. to the level of the Pareto Principle (80:20), the WIS rules link the metadata record ownership to the data owner - at least to the corporate level. So making the field mandatory would add little value - and consistency with the ISO standard in such cases is a benefit. So you have convinced me of optional. I'll leave the document as it is with the comment in place - there will be another iteration.

To answer Ted's question, it is not the number of GISCs that is the issue, but the number of metadata records that will need to refer to them. There will be tens of thousands of metadata records, owned by hundreds of users with varying degrees of competence in maintaining records. I am concerned that if we ask metadata managers to change their records every time a GISC comes onstream, which will happen about ten times in the next 2-3 years, we will really turn them off the idea of maintaining metadata, and train them that making changes to the metadata is something they do in response to someone else's change, rather than something they initiate themselves to improve the effectiveness of their metadata and use of their data.

Steve

---

The information contained in this electronic message and any attachments are intended for specific individuals or entities, and may be confidential, proprietary or privileged. If you are not the intended recipient, please notify the sender immediately, delete this message and do not disclose,  distribute or copy it to any third party or otherwise use this message. The content of this message does not necessarily reflect the official position of the World Meteorological Organization (WMO) unless specifically stated. Electronic messages are not secure or error free and may contain viruses or may be delayed, and the sender is not liable for any of these occurrences.

---

SAVE PAPER - Please do not print this e-mail unless absolutely necessary

--

__________________________________________________
Dr Steve Foreman
Chief, Data Representation, Metadata and Monitoring
World Meteorological Organization

 

Tel: +41 22 730 8171

Email: sfor...@wmo.int

---

The information contained in this electronic message and any attachments are intended for specific individuals or entities, and may be confidential, proprietary or privileged. If you are not the intended recipient, please notify the sender immediately, delete this message and do not disclose,  distribute or copy it to any third party or otherwise use this message. The content of this message does not necessarily reflect the official position of the World Meteorological Organization (WMO) unless specifically stated. Electronic messages are not secure or error free and may contain viruses or may be delayed, and the sender is not liable for any of these occurrences.

---

SAVE PAPER - Please do not print this e-mail unless absolutely necessary

[Jeremy Tandy]

Ted. Responding to your comments: 

reh2: (pg4) planning for changes to name spaces and schema locations will need to be part of our move to ISO 19115-1 for 2014.

reh7: (pg6) I refer to 19139 in this section because the rule is about the XML encoding.

reh10: (pg9) I don't think the SRU search is mapped only to keywords of type theme. I make the linkage explicit for WMO core metadata profile a little further on.

reh13: (pg10) examples will be in the guidance doc that eiji is writing.

reh20: (pg14) we need to be consistent with our existing usage over past 2 years; "License" stays.

Thanks for input. Have incorporated (most) changes. Jeremy

[ted Habermann]

Steve,

Thanks for the clarification.. Makes sense to me.

Ted

[Eizi]

Hi Jeremy,

Sorry I'm slow reader. One thing pops up to my attention: Ban on default namespace.

Two years ago Mike called it unnatural to regulate use of NS prefix.  I'm not sure what's conclusion between him and Ted.  If there is really software that breaks at default namespace, that's fine for me at least.

On the other hand I know it is convenient if we can assume standardized namespace prefixes like "gmd:" or "gco:".  The draft looks like at halfway.  How about recommending prefixes (like gmi:/gmx:/gml:) ?

Eizi

[Ted Habermann]

Eizi et al.,

I think Mike ended up agreeing that default namespaces were not a great idea. I think it is generally a good practice to unambiguously identify the element names we use. Also, the default namespace prefixes are in 19139... I don't think we need to specify them...

Ted

[Jeremy Tandy]

All - 

I've now incorporated feedback from the first round (I'll cross-reference with Steve's updates whilst I am here in Geneva for the ICT-ISS meeting ... Wed-Fri this week).

I have also written the abstract test suite.

We're making progress. Track changes is ON so you should quickly be able to find the changes.

Most importantly, I have decided to _REMOVE_ statements about gmd:distributionInfo from the WMO Core Metadata Profile specification. We have not had a chance to work through this requirement robustly and check to ensure we have the right approach. Ted's mail from earlier is indicative. Instead, we develop & publish GUIDANCE for the distribution information for globally exchanged data in (slightly) slower time.

Attached for review ...

Jeremy

[Michael Burek]

Hi Eizi, Ted,

Unnatural is probably not the word I would use.  My concern was that XML as it is commonly used in practice usually contains a default namespace, and so to force the issue could be a barrier to adoption.  I think we agreed to allow a default namespaces, with a guidance recommendation that better practice would be to not use default namespaces, and we had some examples of that in the 1.2 doc. I don't think there is a great difference in terms of practice, but am happy to join in this recommendation. I also like the symmetry of not having one special case default namespace. When one starts thinking about XML fragments as Ted has proposed, I also think there is a persuasive case to be made that requiring all elements have an explicit namespace is essential to that endeavor.

Hope that helps clarify.

Mike

[Michael Burek]

Hi,

I added comments, draft geo-extent guidance, and relabeled the file name 0.2.1r...

Mike

[Jeremy Tandy]

Thanks Mike - changes incorporated.

I'll wait for a few more updates before circulating another release.

Jeremy

[Seib Jürgen]

Hi,

 

I made some comments on pages 9 and 12.

 

Jürgen

 

---

Von: wmo-i...@googlegroups.com [mailto:wmo-i...@googlegroups.com] Im Auftrag von Michael Burek
Gesendet: Dienstag, 12. Juni 2012 23:05
An: wmo-i...@googlegroups.com
Betreff: Re: Draft WMO Core Metadata Profile specification document for review

[Jeremy Tandy]

Jürgen ...

your comment on Page 9:

>>

SRU is mandatory for each GISC. CSW is optional und must not be provided by a GISC.

<<

Should we remove the reference to CSW?

your comment on Page 12:

>>

Having more than one bounding box  makes spatial search complicated. I suggest the following restriction:

Each WIS Discovery Metadata record describing geographic data shall include the description of one and only one geographic bounding box defining a coverage for  the data

<<

Whilst it is not common, it is not unusual for data to describe multiple extents. I think that we might develop a Style Guideline recommending a single Bounding Box, but the formal requirements in the Specification must allow the definition of multiple extents. I  propose _NOT_ to incorporate this suggested change.

Thanks, Jeremy

[Seib Jürgen]

Jeremy,

---

Von: wmo-i...@googlegroups.com [mailto:wmo-i...@googlegroups.com] Im Auftrag von Jeremy Tandy
Gesendet: Mittwoch, 13. Juni 2012 19:02

An: wmo-i...@googlegroups.com
Betreff: Re: Draft WMO Core Metadata Profile specification document for review

Jürgen ...

your comment on Page 9:

>>

SRU is mandatory for each GISC. CSW is optional und must not be provided by a GISC.

<<

Should we remove the reference to CSW? 

>> JS: Yes. Our task is the specification of metadata descriptions, not the services to access the metadata.

your comment on Page 12:

>>

Having more than one bounding box  makes spatial search complicated. I suggest the following restriction:

Each WIS Discovery Metadata record describing geographic data shall include the description of one and only one geographic bounding box defining a coverage for  the data

<<

Whilst it is not common, it is not unusual for data to describe multiple extents. I think that we might develop a Style Guideline recommending a single Bounding Box, but the formal requirements in the Specification must allow the definition of multiple extents. I  propose _NOT_ to incorporate this suggested change. 

>> JS: ok. 

[Ted Habermann]

Jürgen,

The point you raise is why we decided to suggest an xml id on the bounding extent. It allows the metadata creator to specify which of the extents is to be used in simple searches and allows that extent to be identified by xPath. The situation is complicated by the fact that there can also be multiple temporal extents. That may be more common in WMO metadata???

Wanted to also mention that the records used in the consistency work by China are now in a WAF at http://www.ngdc.noaa.gov/metadata/published/WMO/WIS-TEST/iso/. This demonstrates the WMO rubric and, soon, the WMO schematron (we are having some CSS challenges there)...

Ted

[Jeremy]

Jürgen  ... reference to CSW removed.

On Thursday, June 14, 2012 10:22:33 AM UTC+1, Seib Jürgen wrote:

Jeremy,

---

Von: wmo-i...@googlegroups.com [mailto:wmo-ipetmdi@googlegroups.com] Im Auftrag von Jeremy Tandy

Gesendet: Mittwoch, 13. Juni 2012 19:02
An: wmo-i...@googlegroups.com
Betreff: Re: Draft WMO Core Metadata Profile specification document for review

Jürgen ...

your comment on Page 9:

>>

SRU is mandatory for each GISC. CSW is optional und must not be provided by a GISC.

<<

Should we remove the reference to CSW? 

>> JS: Yes. Our task is the specification of metadata descriptions, not the services to access the metadata.

your comment on Page 12:

>>

Having more than one bounding box  makes spatial search complicated. I suggest the following restriction:

Each WIS Discovery Metadata record describing geographic data shall include the description of one and only one geographic bounding box defining a coverage for  the data

<<

Whilst it is not common, it is not unusual for data to describe multiple extents. I think that we might develop a Style Guideline recommending a single Bounding Box, but the formal requirements in the Specification must allow the definition of multiple extents. I  propose _NOT_ to incorporate this suggested change. 

>> JS: ok. 

Thanks, Jeremy

On 13 June 2012 16:21, Seib Jürgen wrote:

Hi,

 

I made some comments on pages 9 and 12.

 

Jürgen

 

---

Von: wmo-i...@googlegroups.com [mailto:wmo-ipetmdi@googlegroups.com] Im Auftrag von Michael Burek

Gesendet: Dienstag, 12. Juni 2012 23:05
An: wmo-i...@googlegroups.com
Betreff: Re: Draft WMO Core Metadata Profile specification document for review

Hi,

I added comments, draft geo-extent guidance, and relabeled the file name 0.2.1r...

Mike

On Tue, Jun 12, 2012 at 11:24 AM, Michael Burek wrote:

Hi Eizi, Ted,

Unnatural is probably not the word I would use.  My concern was that XML as it is commonly used in practice usually contains a default namespace, and so to force the issue could be a barrier to adoption.  I think we agreed to allow a default namespaces, with a guidance recommendation that better practice would be to not use default namespaces, and we had some examples of that in the 1.2 doc. I don't think there is a great difference in terms of practice, but am happy to join in this recommendation. I also like the symmetry of not having one special case default namespace. When one starts thinking about XML fragments as Ted has proposed, I also think there is a persuasive case to be made that requiring all elements have an explicit namespace is essential to that endeavor.

Hope that helps clarify.

Mike

====  ==================

[Seib Jürgen]

Hi Ted,

 

thank you for your explanations. Do we had an agreement on the name for xml:id? I think that we should recommend the use of a specific word, e.g. "WIS". This name should be mentionned in the restriction.

 

Each WIS Discovery Metadata record describing geographic data shall include the description of a geographic bounding box with the xml:id "WIS".

 

Does this make sense?

 

Jürgen

---

Von: wmo-i...@googlegroups.com [mailto:wmo-i...@googlegroups.com] Im Auftrag von Ted Habermann
Gesendet: Donnerstag, 14. Juni 2012 14:08

[Jeremy Tandy]

At this stage I would prefer these recommendations about gml:id for the bounding box extent to be issued as guidance rather than in the formal specification. In which case the statement might be:

Each WIS Discovery Metadata record describing geographic data SHOULD include ...

Once we're happy that the guidance is robust, we can migrate the guidance into the formal requirements in the specification. 

Do we agree?

Jeremy

[Seib Jürgen]

Yes.

---

Von: wmo-i...@googlegroups.com [mailto:wmo-i...@googlegroups.com] Im Auftrag von Jeremy Tandy

Gesendet: Freitag, 15. Juni 2012 10:37

[TOYODA Eizi]

Yes too.

 

One thing I'd like to remark (probably not inormational for people here).  Attributes gml:id and id are of xs:ID type, which must be unique within an XML document.  It is defined so to be useful for search.

 

I saw some people complain that schema validation fails for an XML that combines multiple MD_Metadata docs, for example OAI or SRU responses.  I just wanted to reconfirm it's not a problem, and schema validation should not be done for such big document at once.

 

Eizi

[Jeremy Tandy]

Thanks.

[ted Habermann]

Jergen et al.,

I think the id value should be as descriptive as possible, given the kinds of limitations that Eizi mentions. Our choice is "boundingExtent". Others are described at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Extents...

I have a set of schematron rules that implements this suggestion correctly (I think),

Ted

[Jeremy]

Hi - attached is a new version of the WMO Core Metadata Profile specification. All changes made thus far have been accepted, so if you want to check the differences, you'll need to do a diff with an older version.

The document is split into two parts to ease maintenance; the first part describes conformance with the specification whilst the second part is the abstract test suite and other supporting information. I imagine that as we release new versions of the specification, we will add new clauses to part one. The split document means that these additions will not affect the numbering of part two.

There are still a few comments to consider and a few references that we need to finalise. 

Steve has promised to check that any 'non-regulatory' information is marked as "note" ... plus other WMO Regulation style stuff.

Section 4 currently only has one definition in it. Clearly, if that's all we need, we can keep the section short. However, I am sure that there are some other terms that may need further elaboration. Please can someone take a look at this? (best to update this Google-Group Thread first if you are doing this to make sure we don't double task.

Many thanks; we're nearly there with this doc.

Jeremy

[Steve Foreman]

All,

I have redrafted the document on the method of managing the metadata standard. Please check this carefully as it will become part of a document to be submitted to CBS.

As a result of concerns that our use of the term "validation" in "validation rules" would be confusing in a WMO context, I have used the term "conformance checking rules" instead.

I am about to start editing the "Specification" documents that Jeremy sent round. I will download the last version on this thread that is submitted before 0800 Geneva time on 21 June. I will post the updated copies as soon as I can. Please avoid updating the documents while I have them "checked out" - it will make change tracking easier if we do that.

Thanks

Steve

[Steve Foreman]

All,

I am still talking with the editors on what to call the different structures associated with the documents. The current draft is based on the Manual on WIS being in two parts, of which the metadata definition is Part II. The specifications of metadata versions will then be Appendixes to Part II. The two documents forming the specification then become "parts 1 & 2" of the attachment. All very confusing - but all this can be finalised when we get to the formal editorial stage.

At the moment, we need to get the technical details right. So here are the documents, re-styled but technically the same as before except where I have commented in the change control. The change I have knowingly made to the technical meaning is to say that the metadata records must be in English (at least).

Steve

[ted Habermann]

Jeremy,

A couple of quick finds:

2.2.3:

hierarchyLevel instead of jierarchyLevel 

nonGeographicDataset instead of nonGeographicDataSet

Ted

[Jeremy Tandy]

thanks Ted, I'll include these in the list I am compiling for Steve. Jeremy

[Jeremy Tandy]

Steve ... thanks for your editorial efforts to bring this together. I have decided to bring out the changes I notice in this email rather than posting an updated document. That way you can work through the amendments to ensure that they are correctly incorporated in your master copy.

Additions in BLUE, deletions in RED.

CBSdraft-MetadataManWIS-d3:

-[para 2.1.7] ... irrespective of whether users want to take advantage of a change, a major increment will require changes to software.

Version numbers of the WMO Core Metadata Profile have the form a.b.c  where:

a  shall be incremented if the change requires modifications to software for users that do not wish to take advantage of the change (for example moving to a new version of the ISO 19115 standard). [...] 

b shall be incremented if changes to conformance checking rules or changes to Code Lists are made introduced with mandatory compliance. [...]

c shall be incremented if the changes have no impact on existing metadata records that do not need to use the change (for example adding a new entry to a Code List, or introducing a conformance checking rule that results in a warning rather than causing a metadata record to be declared invalid). [...]

Note: development versions of the WMO Core Metadata Profile, not intended for operational use, are denoted by the digit 0 in second part of the version number. For example: 2.0.1. Development versions are intended to enable the development of a new version of the WMO Core Metadata Profile requiring changes to software systems.

-[para 2.5.1] Where an error in the specification of a CodeList is found (e.g. typo error or incomplete definition etc.) I would prefer the CodeList entry to be amended and re-published. The CodeList dictionary itself (the XML document) shall increment its version number. I have also tended to include a change-log in the XML document. _ONLY_ if the correction is a substantive change (e.g. it changes the semantics of the entry) should a new CodeList entry be created and the existing (erroneous) entry deprecated.

WMO_Core_Metadata_Profile_v1.3_Specification_Part_1_v0.6DRAFT:

-[para 5.3]

The majority of All of the model elements used within the WMO Core Metadata Profile are defined in ISO geographic information standards. [...]

-[para 6.1]

INote: not all XML validation tools implement the full W3C XML Schema [...]

-[para 8.1] (final bullet point on the structure of fileIdentifiers)

for metadata records describing other products, the unique identifier may be assigned by the citation authority so as to be unique among the identifiers assigned by the citation authrority authority.

-[para 8.1] I agree with you suggestion to remove the reference to ISO 8601 topic in Wikipedia

-[para 8.2] reference was incorrect; Part 2, Table 13 is MD_TopicCategoryCode, whilst Part 2, Table 16 is WMO_CategoryCode.

A new Code List Dictionary is published as part of this specification defining the set of permissible values for WMO_CategoryCode (see Part 2, Table 1316). Keywords from WMO_CategoryCode shall be of type ‘theme’.

-[para 8.2] amendment to the additional language requirement ... formatting & move the optional statement into separate sentence:

The primary language used in metadata conforming to the WMO Core Metadata Profile is English. Translations of English elements within the record may also be included.

8.2.5 All information contained within a metadata record shall be provided in English within the metadata record. 

Translations of all or part of the English content may also be included.

-[para 9.1] change the reference to match previously used style:

A new Code List Dictionary is published as part of this specification defining the set of permissible values for specifying the scope of distribution within the WIS: WMO_DistributionScopeCode; Part 2, Table 17 (Part 2) refers.

-[para 9.3] typo ...

Mote Note: only exact matches to the terms from the codelist are acceptable; "wmo-essential", "WMO Essential", or "WmOaDdiTiOnaL" will all fail to validate.

-[para 9.3] change the reference to match previously used style:

A new Code List Dictionary is published as part of this specification defining the set of permissible values for specifying the WMO Data Policy: WMO_DataLicenseCode; Part 2, Table 14 (Part 2) refers.

[...]

A new Code List Dictionary is published as part of this specification defining the set of permissible values for specifying the WMO Data Policy: WMO_GTSProductCategoryCode; Part 2, Table 15 (Part 2) refers

-[para 9.3] amendment for consistency with DataPolicyCode

Note: only Only exact matches to the terms from the codelist are acceptable; "gts-priority-4", "GTS Priority 4", or "GtsPriority4" will all fail to validate.

-[para 9.3] more typos ... (also, please check whether you meant to have inconsistent formatting in the metadata element names I have highlighted in GREEN)

However, this is should be made explicit by expressing
gmd:MD_LegalConstraints/gmd:accessConstraints and
gmd:MD_LegalConstraints/gmd:useConstraints using
gmd:MD_RestrictionCode “otherRestrictions”.

Note: and example is

[...]

-[para 10] consistency - remove the word Clause. Also you will need to remove the word 'Clause' from the captions for Tables 4, 5 & 6.

The requirements defined in this specification are summarised below in Table 4, Table 5 and Table 6. They are grouped according to the encoding requirements expressed in Clause 6 and the formal requirements expressed in Clauses 8 and 9.

-[para 11] change the reference to match previously used style:

Table 7 lists the modifications and additions to the Code Lists defined in ISO 19115:2003. Please refer to Clause Part 2, 4 (Part 2) for more information on Code List extensions.

-[para 11, Table 7] all the references in the table to Part 2 need to be updated from 'See Table nn (Part 2)' to 'See Part 2, Table nn' to be consistent with the rest of the document.

-[para 12] change the reference to match previously used style:

Details of the UML classes and attributes are provided in Clause Part 2, 3 (Part 2).

WMO_Core_Metadata_Profile_v1.3_Specification_Part_2_v0.3DRAFT

-[para 2.2.2] the identifier (Test id) for second test (for Requirement 8.2.2) suffers from copy & paste ...

Test id:                        http://wis.wmo.int/2012/metadata/conf/WMO_CategoryCode-keyword-cardinalityWMO_CategoryCode-keyword-theme

-[para 2.2.3] the identifier (Test id) for first test (for Requirement 8.2.4) suffers from copy & paste ...

Test id:                        http://wis.wmo.int/2012/metadata/conf/keyword-groupinggeographic-bounding-box

-[para 2.2.3] (thanks Ted)

Test method:   (i) Inspect the instance document under test to assess whether the metadata record is describing geographic data; e.g.

/gmd:MD_Metadata/gmd:jierarchyLevelhierarchyLevel/gmd:MD_ScopeCode != “nonGeographicDataSetnonGeographicDataset”

-[para 2.2.3] between 2.2.3 and 2.3 add a statement indicating that no conformance test exist for the language requirement you added; e.g.

Note that there is no abstract test for Requirement 8.2.5: All information contained within a metadata record shall be provided in English within the metadata record.

-[para 2.3.1] the Test id for Requirements 9.1.1 and 9.1.2 have erroneous white space (highlighted in RED):

Test id:                        http://wis.wmo.int/2012/metadata/conf/identification-of- globally-exchanged-data

Test id:                        http://wis.wmo.int/2012/metadata/conf/fileIdentifier-for- globally-exchanged-data

-[para 3, Table 2] in your reformatting you deleted the sub-point reference (I have also highlighted this in YELLOW to make the change easier to see):

33

Role name: descriptiveKeywords

provides category keywords, their type, and reference source

M

N

Association

MD_Keywords See Table 3 See Part 1, 8.2  and Part 1, 9.1

-[para 3, Table 3] mis-spelling of word 'Part' (twice) ... and missed references to Part 1 that need updating

53

keyword

commonly used word(s) or formalised word(s) or phrase(s) used to describe the subject

M

N

CharacterString

Free text See ParetPart 1, 8.2 and artPart 1, 9.1

55

thesaurusName

name of a formally registered thesaurus or a similar authoritative source of keywords

O

1

Class

CI_Citation «DataType» See Table 6 See SubclausesPart 1, 8.2 (Part 1) and Part 1, 9.1 (Part 1)

-[para 3, Table 7] has not had its formatting updated - it is the only Table remaining with the old-style format.

-[para 4] need to update the reference to the location of the normative WMO CodeList Dictionary (these codes may be used by more than just metadata) ... elsewhere in the specification it is defined as: http://wis.wmo.int/2012/codelists/WMOCodeLists.xml

A GML CodeList Dictionary implementation of the new and amended Code Lists is published at: http://wis.wmo.int/2012/metadata/version_1-3/WMOCodelists.xml http://wis.wmo.int/2012/codelists/WMOCodeLists.xml.

-[para 4, Tables 10, 11, 12, 13 & 16] ... this is probably due to MS Word being helpful, but the 'Name' of the terms in these tables has been changed to start with a Capital letter ... these should _ALL_ be lowerCamelCase*; e.g. (from Table 10)

2.

Disciplinediscipline

001

keyword identifies a branch of instruction or specialised learning

* the exception to the lowerCamelCase rule are the WMO_DataLicenseCode, WMO_GTSProductCategoryCode and WMO_DistributionScopeCode code lists ... we seem to have used an UpperCamelCase therein ... but it's too late to change as these are already in use.

Thanks, Jeremy

[Steve Foreman]

Jeremy,

some questions on your changes:

-[para 6.1]

INote: not all XML validation tools implement the full W3C XML Schema [...]

Does this mean that you want the word "recommendation" to be omitted? 

-[para 3, Table 7] has not had its formatting updated - it is the only Table remaining with the old-style format.

Looking at it in print preview - do we really want to remove the lines in the tables? Horizontal lines might help people 

Steve 

[Jeremy Tandy]

1. I only observe the erroneous."I" at the beginning of the sentence ... INote

2. Please choose whatever format works best; I just note the inconsistency.

Jeremy

[Steve Foreman]

Thanks Jeremy - I didn't spot the I - even in this email it was hard. Too much time spent with track changes turned on I think!

Steve

_____________________

Steve Foreman

[Steve Foreman]

Hi everyone,

I have now finished the style edits and other changes that Jeremy has agreed so far. I attach the latest version of the three documents.

I am starting to work on the formal documents for CBS. These documents will become annexes to the formal CBS document - so we need to agree them this week.

Steve

[Steve Foreman]

[TOYODA Eizi]

Steve,

 

How can I help you?

 

I guess the documents (annexes to the formal CBS docs) include something we called guidance or guide in May meeting.  It's assigned to me.

 

Best,

Eizi

[Steve Foreman]

All,

I have edited the code list xml file. I intended to make it consistent with the latest version of the specification.

Intended changes were to: 

CI_DateTypeCode: - change text of description so it displayed properly in WordPad

WMO_DataLicenseCode: Remove spaces from names and values. Update descriptions. Add WMOOther.

WMO_GTSProductCategoryCode: remove spaces; change identifiers to GTSPriorityn (follows pattern of other code tables) - and change the purely numeric identifier with the full identifier (that is, do not use the code list number)

WMO_DistributionScopeCode: add table

We have also added "dataCentre" to MD_KeywordTypeCode. I have cut out the relevant list from the ISO code lists - but someone who knows what they are doing should check what I have done - for example I have still left in the TC211 reference (on the basis that it is in the later standard). - this is the last group in the file.

I have not tidied up the indentation of that bit either.

Steve

[Fechner Siegfried]

Hello Steve,

 

could it be that the code_list.xml some mistakes (character set problems and xml structure)? I will send detail on Monday.

 

Best regards

Siegfried

---

Von: wmo-i...@googlegroups.com [mailto:wmo-i...@googlegroups.com] Im Auftrag von Steve Foreman
Gesendet: Mittwoch, 27. Juni 2012 18:03
An: wmo-i...@googlegroups.com
Betreff: Re: Draft WMO Core Metadata Profile specification document for review

[Steve Foreman]

All

Juergen sent me a corrected version - I will post it to the group.

Steve

__________________________________________________
Dr Steve Foreman.
Chief, Data Representation, Metadata and Monitoring.
World Meteorological Organization.

Tel: +41 22 730 8171

---

The information contained in this electronic message and any attachments are intended for specific individuals or entities, and may be confidential, proprietary or privileged. If you are not the intended recipient, please notify the sender immediately, delete this message and do not disclose,  distribute or copy it to any third party or otherwise use this message. The content of this message does not necessarily reflect the official position of the World Meteorological Organization (WMO) unless specifically stated. Electronic messages are not secure or error free and may contain viruses or may be delayed, and the sender is not liable for any of these occurrences.

---

SAVE PAPER - Please do not print this e-mail unless absolutely necessary

[Steve Foreman]

Apologies if this is the second post of Juergen's changes to the code list file. I had to re-login to the wifi and don't know if the first went.!

Steve

__________________________________________________
Dr Steve Foreman.
Chief, Data Representation, Metadata and Monitoring.
World Meteorological Organization.

Tel: +41 22 730 8171

---------- Forwarded message ----------
From: "Seib Jürgen" <Juerge...@dwd.de>
Date: Jun 28, 2012 12:06 PM
Subject: AW: Draft WMO Core Metadata Profile specification document for review
To: "Steve Foreman" <sfor...@wmo.int>

The attached file contains well-formed XML code.

 

Jürgen

 

PS: A good way to test the well-formedness of an XML file is the opening of the file with a web browser, e.g. IE or Firefox.

---

Von: Steve Foreman [mailto:sfor...@wmo.int]
Gesendet: Donnerstag, 28. Juni 2012 09:25
An: Seib Jürgen

Betreff: Re: Draft WMO Core Metadata Profile specification document for review

Jurgen

given that I only have WordPad or NotePad to edit, it would be difficult to spot these. I changed some strange characters in the original - but probably missed some that displayed OK.

Can you edit them out, or at least tell me where they are?

Thanks

Steve

On 28 June 2012 08:50, Seib Jürgen <Juerge...@dwd.de> wrote:

Hi Steve,

 

the attached XML file is not well formed. XML Spy returns an error at line 104: "gmx:codeEntry closing element name expected". Firefox is also not able to parse the file. It seems that there are a couple of characters which are not UTF-8.

 

Jürgen

---

Von: wmo-i...@googlegroups.com [mailto:wmo-i...@googlegroups.com] Im Auftrag von Steve Foreman
Gesendet: Mittwoch, 27. Juni 2012 18:03
An: wmo-i...@googlegroups.com
Betreff: Re: Draft WMO Core Metadata Profile specification document for review

--

__________________________________________________
Dr Steve Foreman

Chief, Data Representation, Metadata and Monitoring

World Meteorological Organization

 

Tel: +41 22 730 8171

Email: sfor...@wmo.int

---

The information contained in this electronic message and any attachments are intended for specific individuals or entities, and may be confidential, proprietary or privileged. If you are not the intended recipient, please notify the sender immediately, delete this message and do not disclose,  distribute or copy it to any third party or otherwise use this message. The content of this message does not necessarily reflect the official position of the World Meteorological Organization (WMO) unless specifically stated. Electronic messages are not secure or error free and may contain viruses or may be delayed, and the sender is not liable for any of these occurrences.

---

SAVE PAPER - Please do not print this e-mail unless absolutely necessary

[Steve Foreman]

Juergen's corrected version of the code list.

Steve

--

__________________________________________________
Dr Steve Foreman
Chief, Data Representation, Metadata and Monitoring
World Meteorological Organization

 

Tel: +41 22 730 8171

Email: sfor...@wmo.int

---

The information contained in this electronic message and any attachments are intended for specific individuals or entities, and may be confidential, proprietary or privileged. If you are not the intended recipient, please notify the sender immediately, delete this message and do not disclose,  distribute or copy it to any third party or otherwise use this message. The content of this message does not necessarily reflect the official position of the World Meteorological Organization (WMO) unless specifically stated. Electronic messages are not secure or error free and may contain viruses or may be delayed, and the sender is not liable for any of these occurrences.

---

SAVE PAPER - Please do not print this e-mail unless absolutely necessary

[Fechner Siegfried]

Good morning,

 

as attachment i send you last posted file by Steve "WMOCodelists.xml.steve" from 29. June 2012 16:31 (wellformed but not valited) and an alternative proposal ("WMOCodelists.xml").

 

Best regards

Siegfried

---

Von: wmo-i...@googlegroups.com [mailto:wmo-i...@googlegroups.com] Im Auftrag von Steve Foreman

Gesendet: Freitag, 29. Juni 2012 16:31
An: wmo-i...@googlegroups.com
Betreff: Fwd: AW: Draft WMO Core Metadata Profile specification document for review

[Jeremy Tandy]

Steve - I have cross referenced your updates with the amendments I suggested. I notice a couple of errors to fix. I have kept the same RED / BLUE highlight to indicate deletion/addition.

WMO_Core_Metadata_Profile_v1.3_Specification_Part_1_v0.7DRAFT: 

-[para 9.1] miss-spelling of "Part"

A new Code List Dictionary is published as part of this specification defining the set of permissible values for specifying the scope of distribution within the WIS: WMO_DistributionScopeCode; PatPart 2. Table 17 refers.

WMO_Core_Metadata_Profile_v1.3_Specification_Part_2_v0.4DRAFT:

-[para 2.2.3] erroneous 'space' character ... highlighted in RED. ... plus extra word remaining from old draft that needs to be removed

Test id:                        http://wis.wmo.int/2012/metadata/conf/ groupinggeographic-bounding-box 

-[para 3, Table 2] in your latest amendment you erroneously added a full stop ... I know this is pedantic but :-)  (I have highlighted this in YELLOW to make the change easier to see):

33

Role name: descriptiveKeywords

provides category keywords, their type, and reference source

M

N

Association

MD_Keywords See Table 3 See Part 1, 8.2.  and Part 1, 9.1

-[para 4, Tables 10] typo ... 

4.

ptratumstratum

003

keyword identifies a the layer(s) of any deposited substance

I also note that we still have some yellow highlighting in the document; e.g.

http://wis.wmo.int/2012/codelists/WMOCodeLists.xml

I only did this to make it easy to spot the reference so I could remember to make sure they were all updated and consistent. The yellow highlight can be removed.

Jeremy

[Steve Foreman]

Hi everyone

I am now editing the documents into their final form - and am including these comments of Jeremy.

Steve

[Jeremy]

Hi ... thank you Siegfried for the proposed change. I only spotted reformatting of the xml elements (e.g. indenting) to improve readability).

In the attached XML document, I have deleted the text that Siegfried commented out and have kept his changes verbatim. Additionally, I have removed the gml:name elements from the document as we agreed in a previous discussion that these served no appreciable purpose ... gml:identifier provides the authoritative identifier for each term. This is consistent with the other GML Code-lists from ISO/TC211.

I also notice that the CodeSpace for MD_KeywordTypeCode "dataCentre" is provided as ISOTC211/19115 ... as we are including this as an amendment there is an argument to indicate the codespace as wmo core metadata profile. however, in this case, I am satisfied that we are 'borrowing' from ISO/DIS 19115-1:2013(E) so specifying the codespace as ISOTC211/19115 is acceptable.

Jeremy

[Jeremy]

And the XML document is now attached.

[Steve Foreman]

All,

I will include this version of the code list in the issued package.

Steve

---

The information contained in this electronic message and any attachments are intended for specific individuals or entities, and may be confidential, proprietary or privileged. If you are not the intended recipient, please notify the sender immediately, delete this message and do not disclose,  distribute or copy it to any third party or otherwise use this message. The content of this message does not necessarily reflect the official position of the World Meteorological Organization (WMO) unless specifically stated. Electronic messages are not secure or error free and may contain viruses or may be delayed, and the sender is not liable for any of these occurrences.

---

SAVE PAPER - Please do not print this e-mail unless absolutely necessary

--

__________________________________________________
Dr Steve Foreman
Chief, Data Representation, Metadata and Monitoring
World Meteorological Organization

 

Tel: +41 22 730 8171

Email: sfor...@wmo.int

[TOYODA Eizi]

Hi Steve,

 

Thanks so much for your efforts.  So sorry for slow response.  I'm trying to implement metadata generator for the new standard docs, and finally I'm getting understand it.

 

I'm so sorry that my dumb eyes didn't alarm me as WMO_CategoryCode has revived after years of absence.  It was not paid attention in IPET-MDI activities.  Of course it is definitely good thing to have subcategories of meteorology community.  But I feel like the list needs some polish-up.

 

One reaction from people working on observation of trace gases (ozone and greenhouse gases) is that their work is not finding appropriate category.  They are not happy with "pollution" series since many gases (like ozone) exists more naturally than by human emission.  "Meteorology" should be kept as last resort.

 

Even for GTS data, the applicability of the codelist was not yet proven.  Today I made a mapping from data categories described in the GTS Manual (cf. attached GTSHeadings table).  My findings:

 

 - It looks unbalanced if we have satelliteObservation but not radarObservation.

 - Data made for aviation community might be better to have own category like "aviationMeteorology" in parallel to agriculturalMeteorology

 - Space weather data (radio forecast) and Tsunami forecast/warning should have their homes too.

 - Many existing codeList entries are either place-oriented (ex. landHydrology) or specialization-oriented (ex. weatherForecast). It is illustrated in a mostly-blank matrix (cf. attached Matrix table).  Some data have both attributes.  I mean where the flood forecast should be classified?  Only pollution seems to have enough line-up in the matrix.

 

If the regulation were unchangeable forever, I would have to throw many least-relevant things into the category with broadest meaning i.e. "meteorology".  It would soon be a victim of "misc syndrome" that is little more than garbage box.

 

I know it's bit too late for CBS.  It is perfectly no problem we leave the items for the first fast track of metadata.  But I just wanted to share my findings (PDF is also available at Google Docs http://goo.gl/udqxx).

 

Best,

Eizi

----- Original Message -----

From: Steve Foreman

To: wmo-i...@googlegroups.com

Sent: Tuesday, June 26, 2012 4:48 PM

[Steve Foreman]

Eizi

Good point - and you are right, we can use the fast track procedure.

Perhaps you could and the TT-ApMD members could prepare a list of suggestions?

Thanks

Steve

---

The information contained in this electronic message and any attachments are intended for specific individuals or entities, and may be confidential, proprietary or privileged. If you are not the intended recipient, please notify the sender immediately, delete this message and do not disclose,  distribute or copy it to any third party or otherwise use this message. The content of this message does not necessarily reflect the official position of the World Meteorological Organization (WMO) unless specifically stated. Electronic messages are not secure or error free and may contain viruses or may be delayed, and the sender is not liable for any of these occurrences.

---

SAVE PAPER - Please do not print this e-mail unless absolutely necessary

--

__________________________________________________
Dr Steve Foreman
Chief, Data Representation, Metadata and Monitoring
World Meteorological Organization

 

Tel: +41 22 730 8171

Email: sfor...@wmo.int