Specification Profiles, Application Profiles, Layers...

When I spotted the conversation about (definition of) "profiles" on the
EM CAP Profiles SC List [1], I sent Rex a brief note about WS-I, OGC,
DCMI, and (? IIRC) some other SSO arenas in which I'd spotted interesting
profile work.

Here are a few references that may be of interest.  I understand that the
topic (generally) has now been forwarded to the TAB for consideration.

Examples:

* UML Profiles
* Dublin Core Metadata Initiative (DCMI)

Application Profiles
* Open Geospatial Consortium (OGC)

Profiles and Application Profiles

--------------------------------------------------------------------------

UML Profiles

--------------------------------------------------------------------------

"UML Profiles are subsets of UML tailored for specific purposes"

UML Profiles tailor the language to specific areas -- some for
business modeling; others for particular technologies. All of
our standard profiles are available from our Profiles Catalog at
http://www.omg.org/technology/documents/profile_catalog.htm
You'll find these Profiles:

* Platform Independent Model (PIM) & Platform Specific Model

(PSM) for Software Radio Components (also referred to as

UML Profile for Software Radio)
* UML Profile for CORBA and CORBA Component Model (CCM)
* UML Profile for Enterprise Application Integration (EAI)
* UML Profile for Enterprise Distributed Object Computing (EDOC)
* UML Profile for Modeling QoS and Fault Tolerance Characteristics

and Mechanisms
* UML Profile for Schedulability, Performance and Time
* UML Profile for System on a Chip (SoC)
* UML Profile for Systems Engineering (SysML)
* UML Testing Profile

=== 13 Core::Profiles ===
http://www.omg.org/docs/ptc/08-05-04.pdf

The Profiles package contains mechanisms that allow metaclasses
from existing metamodels to be extended to adapt them for different
purposes. This includes the ability to tailor the UML metamodel
for different platforms (such as J2EE or .NET) or domains
(such as real-time or business process modeling). The profiles
mechanism is consistent with the OMG Meta Object Facility (MOF).

=== Extensibility ===

The profiles mechanism is not a first-class extension mechanism
(i.e., it does not allow for modifying existing metamodels).
Rather, the intention of profiles is to give a straightforward
mechanism for adapting an existing metamodel with constructs that
are specific to a particular domain, platform, or method. Each
such adaptation is grouped in a profile. It is not possible to
take away any of the constraints that apply to a metamodel such
as UML using a profile, but it is possible to add new constraints
that are specific to the profile. The only other restrictions
are those inherent in the profiles mechanism; there is nothing
else that is intended to limit the way in which a metamodel is
customized.

First-class extensibility is handled through MOF, where there are
no restrictions on what you are allowed to do with a metamodel:
you can add and remove metaclasses and relationships as you find
necessary. Of course, it is then possible to impose methodology
restrictions that you are not allowed to modify existing
metamodels, but only extend them. In this case, the mechanisms
for first-class extensibility and profiles start coalescing.
There are several reasons why you may want to customize a metamodel:

* Give a terminology that is adapted to a particular platform or

domain (such as capturing EJB terminology like home interfaces,

enterprise java beans, and archives).
* Give a syntax for constructs that do not have a notation

(such as in the case of actions).
* Give a different notation for already existing symbols (such as

being able to use a picture of a computer instead of the

ordinary node symbol to represent a computer in a network).
* Add semantics that is left unspecified in the metamodel (such as

how to deal with priority when receiving signals in a

state machine).
* Add semantics that does not exist in the metamodel (such as

defining a timer, clock, or continuous time).
* Add constraints that restrict the way you may use the metamodel

and its constructs (such as disallowing actions from

being able to execute in parallel within a single transition).

=== Profiles History and design requirements ===

The [UML] Profile mechanism has been specifically defined for
providing a lightweight extension mechanism to the UML standard.
In UML 1.1, stereotypes and tagged values were used as string-based
extensions that could be attached to UML model elements in a
flexible way. In subsequent revisions of UML, the notion of a
Profile was defined in order to provide more structure and
precision to the definition of Stereotypes and Tagged values. The
UML2.0 infrastructure and superstructure specifications have
carried this further, by defining it as a specific meta-modeling
technique. Stereotypes are specific metaclasses, tagged values are
standard metaattributes, and profiles are specific kinds of packages.

The following requirements have driven the definition of profile
semantics from inception:

1. A profile must provide mechanisms for specializing a reference

metamodel (such as a set of UML packages) in such a way that

the specialized semantics do not contradict the semantics of

the reference metamodel. That is, profile constraints may

typically define well-formedness rules that are more constraining

(but consistent with) those specified by the reference metamodel.

2. It must be possible to interchange profiles between tools,

together with models to which they have been applied, by

using the UML XMI interchange mechanisms. A profile must

therefore be defined as an interchangeable UML model. In addition

to exchanging profiles together with models between tools,

profile application should also be definable 'by reference' (e.g.,

'import by name'); that is, a profile does not need to be

interchanged if it is already present in the importing tool.

3. A profile must be able to reference domain-specific UML libraries

where certain model elements are pre-defined.

4. It must be possible to specify which profiles are being applied to

a given Package (or any specializations of that concept). This is

particularly useful during model interchange so that an importing

environment can interpret a model correctly.

5. It should be possible to define a UML extension that combines

profiles and model libraries (including template libraries) into

a single logical unit. However, within such a unit, for

definitional clarity and for ease of interchange (e.g.,

'reference by name'), it should still be possible to keep the

libraries and the profiles distinct from each other.

6. A profile should be able to specialize the semantics of standard

UML metamodel elements. For example, in a model with the profile

'Java model,' generalization of classes should be able to be

restricted to single inheritance without having to explicitly

assign a stereotype 'Java class' to each and every class instance.

--------------------------------------------------------------------------

Dublin Core Metadata Initiative (DCMI)

Application Profiles

--------------------------------------------------------------------------

http://xml.coverpages.org/newsletter/news2009-01-05.html#cite4
http://dublincore.org/documents/2009/01/05/profile-review-criteria/
A new publication by the Dublin Core Metadata Initiative (DCMI)

Usage Board presents guidelines articulating the criteria by
which the DCMI Usage Board reviews an Application Profile. As of
March 2008, the main points of reference for these review criteria
are [...]

http://dublincore.org/documents/2008/01/14/singapore-framework/
Singapore Framework for Dublin Core Application Profiles

http://dublincore.org/documents/2007/06/04/abstract-model/
DCMI Abstract Model

http://dublincore.org/documents/2008/03/31/dc-dsp/
Description Set Profile Specification

http://dublincore.org/groups/collections/collection-application-profile/2007-03-09/
Dublin Core Collections Application Profile

http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile
Eprints Application Profile

--------------------------------------------------------------------------

Open Geospatial Consortium (OGC)

Profilea and Application Profiles

--------------------------------------------------------------------------

OGC Specification Profiles
http://www.opengeospatial.org/standards/profile

The OGC Standards and Specifications
http://www.opengeospatial.org/standards/orm
  OpenGIS Implementation Standards are of five types, three of which
  are Profile, Application Profile, and Application Schema...  In
  the OGC, a GML profile is a restricted subset of the full GML standard.

  "The requirements of an application schema determine the XML Schema

components from the GML schema to be included in a GML profile. GML

defines a variety of conformance classes that apply depending upon

the content of a specific profile..."

"GML Application Schemas: Designers of GML application schemas may

extend or restrict the types defined in the GML schema to define

appropriate types for an application domain. GML application

schemas use applicable GML schema components, either directly or

by specialization, and are valid in accordance with the rules for

XML Schema..."

Schemas and Profiles - What's the Difference?

Ron Lake: Lots of discussion has taken place as to the role of GML

Application Schemas and GML profiles and a lot of this discussion

has been misleading as the two items are often confused with one

another...
http://geoweb.blog.com/419886/

http://xml.coverpages.org/Reed-OGC-200701.html

"in the application layer, a common characteristic is that relatively

simple standards can be developed and deployed that are profiles

or application schemas of other, more "complex" standards such as

GML."

http://lists.oasis-open.org/archives/emergency-cap-profiles/200901/msg00002.html

OGC Releases GML Simple Features Profile Specification for Review
http://xml.coverpages.org/ni2005-07-07-a.html

"EDXL-HAVE - Conformance Statement" (Carl Reed)

By way of background, the OGC has had compliance testing for a
number of our standards for many years. We have recently upgraded
the compliance testing engine (open source) and our members have
developed a Compliance Assertion Language (more on this later). We
have recently added tests for 6 existing OGC standards and some
profiles of those standards, such as GeoRSS GML. Notice we use the
word "compliance". We spend weeks arguing whether we should
have "conformance" testing or "compliance" testing. Turns out that
there are very specific semantics associated with the use of those
words in the context of testing a standard or a profile of a standard
as to whether it meets the mandatory elements of the given standard.
I should also point out that there is a big difference between
compliance testing and interoperability testing. Just because an
implementation of a standard has tested to be compliant does not
guarantee interoperability - it only increases the probability of
interoperability..."
http://lists.oasis-open.org/archives/emergency-msg/200709/msg00041.html

GML Application Schemas and Profiles
http://www.ogcnetwork.net/node/210

--------------------------------------------------------------------------

Random

--------------------------------------------------------------------------
Date: Wed, 31 Dec 2008 02:50:37 +1100
From: Rick Jelliffe