"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Application Profiles

Contents

Related pages



What is a Profile?

ISO 19106- Profiles defines a profile concept that basically says - a profile may take a set of base standards, and restrict it (make it more specific) and/or extend it providing it does not contradict the base standards.

"Specifications of the applications of each referenced base standard or profile, stating the choice of classes or conformance subsets, and the selection of options, ranges of parameter values, for profiles;" [ISO 19106]

The important concept is that a profile is intended to make it possible to implement a standard. Thus, for all domain and architecture modelling purposes, where the focus is on implementation, it is logically necessary to introduce the concept of a profile explicitly.

I.e. each instance implements a particular profile of a base standard, and by doing so provides for interoperability of the instances (a content consideration) as well as interoperability of the technologies (typically a service interface consideration). Without a profile there is no constraint over content, and no interoperability.

Specifications that constrain content are implicity bundling a profile specification along with a interface specification. This does not invalidate the basic model that instantiation requires a profile. Services that have no intention of interoperating, and simply expose content without reference to any external constraint can be seen to be creating a specific, virtual (unpublished), anonymous (unreferenceable), ungoverned profile. If they publish documentation about the service, this is basically just publishing a profile.

So, a common concept of profiles will create improved levels of coherence within implementation architectures.

Special Cases

Metadata Profiles

see MetadataProfiles.

Discovery metadata is required to be highly interoperable, and consequently we see the introduction of profiles being pioneered within existing metadata publishing frameworks.

Service Profiles and Data Access Query Models

see ServiceProfiles

Services are bound to Data Product Specifications (logically), and hence exhibit the need to implement profiles. Implementation experience with WFS in particular, but across data access services in general, has highlighted the need to publish re-usable query models. There is a strong relationship between these query models and the service profiles themselves, and its expected that DAQMs will be able to be formally modelled within a generalised Profile meta-model.

Observations based Feature Types

see ObservationsProfiles

Observations & Measurements provides an information model for Sensor Web Enablement, and many simpler instantiations of real world data. Observations are a generalised concrete class (i.e. it may be soft-typed) that can be applied to virtually any type of content model. Hence, to achieve interoperability it will be necessary to constrain Observations to operate on certain types of FeatureOfInterest and Record.

Modelling Profiles

The ISO 19106 meta-model for Profiles looks something (there is no normative implementation!) like this:

Profile Meta-model:
Profile__Metamodel.JPG

Note that:
  • Profiles can realise multiple base standards
  • Profiles can reference base profiles - it is likely that a "empty" profile of each base standard is required - eg ISO19139 is an implementation profile of ISO 19115
  • The restriction association will need to carry semantic content in the general case
  • no attempt has been made to model the relationship between elements and data types, and restriction may restrict a choice of allowable data types

Progress towards a normative implementation of a profile pattern is required, and will be addressed or recorded here: ProfileModelDevelopment

Outstanding Issues

XML schema implementation

The application of a restriction within XML schema presents special problems - it is not easy to redefine cardinality of elements by restriction whilst leaving the restricted element in the same namespace as the base profile. A suggested approach has been to create profiles by "clone and modify" from the base standard. This appears rather awkward to maintain and there is little evidence of practicality "in the wild".

Given that a similar problem exists with regard to the domain restriction issue, it seems that a single solution should be pursued that allows execution of profiles (eg validation, data entry) by decorating the base schemas rather than redefining them.

The following diagram illustrates the issue
RestrictionProblem.JPG Further discussion can be found at: http://home.badc.rl.ac.uk/lawrence/blog/2006/03/28/some_practicalities_with_iso19139

Binding content

Binding a common semantics to instance-specific contents (domain to range) means finding an approach to express the relationship between classes and externally managed services. UML supports <> and <> but this is clearly inadequate - we dont not want to enumerate values, but rather bind a property to the identifier within a specific instance. We could ignore this, and simply say its content of a given instance, but in fact we want to advertise the rules as a constraint and have all the convenience and rigour of inheritance.

Within UML, we could describe this as a constraint - but we need a pattern to do so.

Within XML, schematron can be used to implement constraints, but its Xpath assertion model doesnt really solve the issue of binding to large remotely managed vocabularies.

On the other hand, its not a particularly complex problem to implement - only to agree on a standard implementation!

See TermResolutionMechanisms

-- RobAtkinson

This is a little tricky as UML and XML Schema are not consistent with each other here. UML permits overrides, even across packages. XML Schema only supports "derivation by restriction" in limited circumstances, and definitely across namespace boundaries.

Because the technologies are incommensurate, it may be that we need (again) to limit our uses of both in order to reside in the intersection.

One approach might be to say that restriction may only be indicated using constraints - i.e. exclude the override idiom from our UML profile altogether. In the XML environment constraints can be implemented using Schematron.

Of course, mapping from OCL to Schematron would be a challenge. And it is also inconvenient since it requires two-pass validation, but it does have the merit of consistency between implementation platforms.

(Does this implementation difficulty perhaps expose the fact that the pattern of defining "general" classes at all, and using these as the basis for specializations that restrict some of the properties, is a bad pattern?)

-- SimonCox - 26 Oct 2006

  • I dont think its a "bad pattern" - since it appears again and again in practice. There are challenges of course, that need reference implementations.

I agree we need to have a UML approach and an equivalent XML implementation, and build this into our application schema management tools and procedures. -- RobAtkinson - 27 Oct 2006 - 09:15
 

Topic attachments
I Attachment Action Size Date Who Comment
Profile__Metamodel.JPGJPG Profile__Metamodel.JPG manage 33.7 K 29 Sep 2006 - 09:49 RobAtkinson Profile Meta-model
RestrictionProblem.JPGJPG RestrictionProblem.JPG manage 28.2 K 29 Sep 2006 - 09:48 RobAtkinson Restriction and namespaces issue
Topic revision: r5 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).