Bryan Lawrence : Bryan's Blog 2006/11/30

Bryan Lawrence

... personal wiki, blog and notes

Bryan's Blog 2006/11/30

A proposal for profiling ISO19139

I've been flagging issues with profiling ISO19139 for some time - see Oct 19 and Aug 15 and especially the comments in the latter.

Over this week a group of us (Rob Atkinson, Simon Cox, Clemens Portele and myself) have been reviewing the reality of problems with profiling ISO19139 and conforming with appendix F of ISO19115.

The following is my summary of what I think we agreed.


We believe the situation is relatively straightforward for extensions to ISO19139:

  1. A given community decides on a profile

  2. The extensions are defined and documented in UML, so that an extended element/class is a specialised class which

    1. lives in a specific profile package

    2. has a different name, and

    3. has an attribute which documents which iso type it is intended to replace.

  3. This new package is then serialised into a new schema,

    • where the new class retains the different name from the UML definition and maintains the gco:isoType attribute to identify the parent (extended iso) element.

  4. and instances are validated against that schema using standard mechanisms.

  5. Interoperability requires that when these instances are made available outside of the community for which the profile is understood, either the producer should transform the document back to vanilla ISO19139 (easily done since all extended elements can be renamed using the iso-type attribute along with removal of material from the new namespace).


We believe that most communities will be profiling ISO19139 by restriction.

Typical restrictions will include (but not be limited to):

  • limiting the cardinality of attributes (e.g. making an optional attribute mandatory),

  • restricting the type of some attributes (e.g. forcing something to be a date where currently a date or a string is allowed).

  • replacing string options with codelists

In all these cases, the resulting instance documents ought conform directly to the parent ISO19139 schema since these restrictions have not introduced new semantics to any element/class - they are simply constraints.

Accordingly, where a community profile wishes to restrict a given element class we recommend that:

  1. The restrictions are defined and documented in UML, so that an restricted element/class is a specialised class which

    1. lives in a specific profile package

    2. has a different name, and

    3. the constraints are modelled using the Object Constraint Language (OCL), and

    4. the specialisation is stereotyped as a <<restriction>> to guide serialisation 12.

  2. These constraints are then serialized as schematron3 commands, which are maintained separately from the profile schema (if it exists - a purely restrictive profile would not require a new schema).

  3. Instances are then validated using the standard XML techniques (which should ensure that they are valid ISO19139) and by a schematron processor.

  4. Interoperability of these instances is trivial given they directly conform to ISO19139 (there is no requirement by the consumer of such a profile to see the constraint serialisation).

For example:

Image: static/2006/11/30/iso19139_restriction.jpg

Right now, the schematron serialisation requires manual (human) interpretation of the OCL to construct the serialisation. It would appear that a direct serialisation of the full power of OCL would be non-trivial, so we are recommending that

  1. communities attempt to use the most simple OCL commensurate with their restricting requirements, and

  2. publicise their best practice, so that eventually

  3. it would be possible to codify the best practice into a "recommended OCL for profile restrictions" document, which would then be amenable to

  4. the development of an automatic parser (that, for example could be built into a future version of [shape change]).

Thus far the only significant criticism of this schematron serialisation approach is that it might not be possible to trivially build a metadata editor which conforms to any arbitrary profile since such tooling would need to be able to both parse the schema and the schematron.

The only other possible approach would be the "clone-and-modify" approach at serialisation. In this case, at serialisation time the schema name changes and the element definitions are directly restricted in the new schema. This new schema then looks like, and behaves like ISO19139, but isn't ISO19139: we believe that inevitable governance issues would arise in the maintenance of the serialisation. Further, like the extension case, instances would need transformation when shared outside the community.

However, it would appear that deploying schematron constraints may not be that difficult in some tools. For example tools exist that can use schematron with xforms.

Further, it is our belief that it will be more easy to deal with hierarchical (and even multiple-inheritance) profiling using the OCL approach as well. For example, an organisation generating metadata may belong to multiple governance domains (e.g. the BADC is a British institution, producing atmospheric data: one might expect our ISO19139 profiles to conform to both the British and WMO standard profiles). It would be easy to test this for restrictions, we simply validate using both schematrons independently!

1: The use of a stereotype for serialisation guidance is the methodology followed in ISO19139 itself. We've chosen restriction here. Although we're not totally comfortable with the particular choice of word, none of us could come up with a better one. (ret).
2: It was suggested that we could do without the stereotype since the serialisation code could simply identify targets for serialisation into schematron alone simply by the fact that the specialisation consisted of OCL alone. However, it is possible that profile maintainers might choose to create real specialisations in an extension (for example, by categorising a particular class into a number of different restricted specialisations, each of which would need to be named). Although that's an extension case, the parser needs to be agnostic as to whether it's an extension or restriction as it processes each element from the UML. (ret).
3: It may be there are other ways of implementing OCL, but schematron seems to be the tool of choice at the moment (ret).

by Bryan Lawrence : 2006/11/30 : Categories ndg metadata iso19115 : 0 trackbacks : 10 comments (permalink)

Wireless Internet Blackspot - Australia

I've spent most of the week in Canberra, Australia, attending three different events - a standards workshop, AUKEGGS and the SEEGRID III conference (programme pdf).

It's been quite a frustrating experience for communication:

  • The hotel I'm staying in has no high-speed internet (despite claiming to do so on it's website!). I would have moved but there appear to be no other hotel rooms available in this town for love nor money (one of the conference attendees has been sleeping on local sofas!).

  • None of the three venues had wireless that could be configured for public access , nor people available to deal with registration onto available networks.

  • The public hotspots (like the one I'm sitting in now) are filthy expensive ($26 Australian for two hours connectivity!), and provide poor connectivity (I can't get my VPN to get up and stay up).

I can get email (at this hotspot), but I have to do it through the braindead outlook web interface ... which in practice means I'm cherry picking a handful of things that a) I spot amongst the deluge, and b) I can deal with. The rest is just building up ... ready to be a millstone around my neck next week.

In a wired and wireless world, connectivity matters. I can't afford to be this out of touch. Do I want to come back to Australia under these circumstances? Nope!

by Bryan Lawrence : 2006/11/30 : 0 trackbacks : 2 comments (permalink)

DISCLAIMER: This is a personal blog. Nothing written here reflects an official opinion of my employer or any funding agency.