fixed: size of OAI set displayed incorrectly

In the WIS community there is a convention that the size of OAI set is
included in ListSet response.

http://www.wis-jma.go.jp/meta/oaiprovider.jsp?verb=ListSets

Until last week there was an problem that the size of WIS-GISC-TOKYO is not
displayed correctly. It is now fixed and it returns reliable number.

The documentation at http://www.wis-jma.go.jp/cms/metadata/oai-pmh/ uses the
ListSets internally, and hence fixed accordingly.

OAI Sync Monitor update

Recent updates of OAI Sync Monitor
http://toyoda-eizi.net/2011/syncmon/mon.html

- Beijing joined and the set WIS-GISC-BEIJING introduced
- Temporary set WIS-UNASSOCIATED introduced
- Testing set WISTEST-* no longer monitored.

metadata updates

- GISC Tokyo has loaded GTS baseline metadata for VBRR, VNNN, VTBB, VLIV,
VMMC, RPMM, VHHH.
- Set WIS-WIMMS created.
- most of WISTEST-JMA set has been deleted; right now deletion in terms of
OAI so other synching centres may harvest that del-notification to react.
Four records are kept just for testing.

WIS Sync Monitor revived

My monitor has been refreshed. It has now updated list of servers and sets,
and there is a bit nicer top page with minimal description.

http://toyoda-eizi.net/2011/syncmon/mon.html

all records in WIS-GISC-TOKYO confirmed to have non-empty dateStamp

Hi,

I've run a test program to check all records in WIS-GISC-TOKYO set. This
time no record has gco:nilReason="missing".

Best,
Eizi

WDCGG metadata updated tentatively

Hi,

I've uploaded 1653 records of DAR metadata for WDCGG. There was problem in
converter from GAWSIS format to ISO 19139, which generated <gmd:dateStamp
gco:nilReason="missing"/> for most of records. Now that should be fixed.

This is only a quick fix: the metadata is all tested to be compliant to ISO
19139 schema, but there should be considerable difference of "style" from
recent agreements in IPET-MDI (and hence the latest version of MF baseline
metadata).

--
Best,
Eizi

resourceFormat and distributionFormat

Now I'm writing schematron to examine how elements of ISO 19115 is used in
actual WIS Initial MD Set.

Today I had to write following schematron.

<pattern name="fmts-eqv">
<!-- activates only if there is resourceFormat -->
<rule context="gmd:resourceFormat">
<assert test="(*/gmd:name/*/text()
=
/*/gmd:distributionInfo/*/gmd:distributionFormat/*/gmd:name/*/text())
or ('BUFR'
=
/*/gmd:distributionInfo/*/gmd:distributionFormat/*/gmd:name/*/text())
or ('CREX'
=
/*/gmd:distributionInfo/*/gmd:distributionFormat/*/gmd:name/*/text())
">resourceFormat/name and distributionFormat/name <!--
-->must be equal, or the latter be BUFR/CREX</assert>
</rule>
</pattern>

Please tolerate I had to write three similar comparisons since libxml2
doesn't support match() function.

The point is resourceFormat/*/name does not necessarily equal to
distributionFormat/*/name. Surprising, isn't it?

That takes place for TDCF (i.e. BUFR and CREX) messages converted from
alphanumeric data. This is very interesting and (so far) practical
approach. But there's also limitation. I'm curious what to do if TDCF is
directly created at the data source.