... personal wiki, blog and notes
Bryan's Blog 2006/11/30
A proposal for profiling ISO19139
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:
A given community decides on a profile
The extensions are defined and documented in UML, so that an extended element/class is a specialised class which
lives in a specific profile package
has a different name, and
has an attribute which documents which iso type it is intended to replace.
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.
and instances are validated against that schema using standard mechanisms.
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:
The restrictions are defined and documented in UML, so that an restricted element/class is a specialised class which
Instances are then validated using the standard XML techniques (which should ensure that they are valid ISO19139) and by a schematron processor.
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).
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
communities attempt to use the most simple OCL commensurate with their restricting requirements, and
publicise their best practice, so that eventually
it would be possible to codify the best practice into a "recommended OCL for profile restrictions" document, which would then be amenable to
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!
Wireless Internet Blackspot - Australia
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)