ProfileContext

From Dataset Exchange Working Group

Definitions of Profile, Application Profile, Metadata Application Profile

Definitions adopted in July 2019

See resolution

" data profile: a data specification that constrains, extends, combines, or provides guidance or explanation about the usage of other data specifications. "

" data specification: a specification, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context. "

Note that these definitions do not define a general notion of specifications or profiles, but apply to specifications of data content.

Draft common definition for "profile"

"A named set of constraints on one or more identified base specifications, including the identification of any implementing subclasses of datatypes, semantic interpretations, vocabularies, options and parameters of those base specifications necessary to accomplish a particular function."[1]

[1](https://www.w3.org/2018/02/06-dxwg-minutes)

--- Notes ---

  • Profiles constrain content, and are distinct from encoding (MIME-type) and language choice.
  • "constraint" [2](https://en.oxforddictionaries.com/definition/constraint) includes specific notions such as owl:restriction.
  • the "set of constraints" may be empty - thus every base specification may act as a "null profile". (This simplifies negotiation and addresses situations where organisations formalise profiles as specifications.)
  • "options" for a specification may include choice of structure (schema) for data objects - noting that more typically profiles would constrain content choices within such schema.

--- Earlier discussion ---

For the purposes of the DXWG a "profile" uses the same form as ISO/IEC TR 10000-1:

"A set of one or more base standards, and, where applicable, the identification of chosen classes, conforming subsets, options and parameters of those base standards necessary to accomplish a particular function."

noting that the scope of "base standards" is relaxed to any standard that is identified by a canonical IRI, and thus can be identified by software agents. Profiles may act as "base standards" for more specialised profiles.

This definition is quite broad, and supports:

  • identification of profiles by IRI
  • specialisation of profiles
  • aggregation/mixing of a set of profiles (and hence polymorphism)
  • a set of one base standards (i.e. a base standard is a simple profile of itself, meaning that only profile conformance needs to be negotiated, rather than base and profile in conjunction)

An "application profile" is a profile that defines the _complete set_ of constraints required for a particular application domain.

Constraints may be described in multiple ways, and not necessarily within a single artefact, a profile will reference one or more descriptions of constraints.

Issues noted

  • a canonical model/vocabulary will need to be identified or provided to describe profile inheritance and relationships to constraint specification documents.
  • determining function equivalence between two profiles involves examining the "set" of base standards, including transitive inheritance. It is yet to be determined if this will be the responsibility of client, server or support services.
  • The Use Cases and derived Requirements for profile guidance suggest that canonical forms of constraint specification will be useful, but no single solution is likely to be suitable for all cases.

Comments/objections

  • I think the "aggregation" bit is especially complex, so we should work to make it clear. I note that many profile definitions include making use of properties/terms from a mix of existing vocabularies. I don't consider that an "aggregation" in this sense, just a normal "borrowing" of vocabulary terms. Another complex idea is inheritance, which was brought up at the first F2F and had strong adherents both for and against. One big question is whether aggregation and/or inheritance are implemented "on the fly" or if they are stable aspects of the profile schema. Karen Coyle (talk) 20:26, 26 January 2018 (UTC)
  • The ISO document defines "base standard" as: "3.1.1 Base Standard: An approved International Standard or ITU-T Recommendation." If we adopt a definition of profile I think we should drop this requirement as our concept of profile is not limited to the ISO universe. Karen Coyle (talk) 20:26, 26 January 2018 (UTC)
    • Thanks for the clarification, Rob. I would like, however, not to insist on IRIs. There are known community standards that can be named or identified but do not have IRIs that identify them. ISO standards are an example. There are XML standards (like ONIX in the publishing community) that do not have IRIs (AFAIK). Yet, like MIME types, these could have names that are used in content negotiation. (I'm interested to hear from Ruben and Lars about their assumptions for handling community standards of this nature.) Karen Coyle (talk) 04:18, 1 February 2018 (UTC)
  • This draft does not seem to reflect a common understanding from the definitions below, but is rather a separate definition. Ruben Verborgh (talk) 20:07, 30 January 2018 (UTC)
  • This definition uses the word “standards” (even within the listed relaxation), but not all profiles are necessarily based on standards. Ruben Verborgh (talk) 20:07, 30 January 2018 (UTC)
  • The difference with a media type, which is crucial for content negotiation, is lost. Ruben Verborgh (talk) 20:07, 30 January 2018 (UTC)
  • The definition is so broad that too many things could be a profile. For instance, a media type also matches that definition. Even worse, a programming language like JavaScript matches the definition, because it is a set of one of more base standards, the "where applicable" part doesn't apply (so that's covered), and it accomplishes a particular function. Ruben Verborgh (talk) 20:07, 30 January 2018 (UTC)
  • I like this definition, but recognize Ruben's worry, that it opens the door to many things. I think it would be fair in our context (i.e. data exchange) to add that we restrict the notion of profile to data vocabularies: "A set of one or more base data vocabularies [pointing to existing definitions on the W3C site, maybe the DWBP discussion] [...] necessary to express data that is needed to perform a particular function". Btw I think it also address Ruben's worry about using the word 'standard' (I also agree here), which then would disappear from the definition. Antoine Isaac (talk) 11:56, 31 January 2018 (UTC)

Discussion of Definitions

Ruben Verborgh

Term: media type

A media type (or content type) is a set of syntactic constraints, structural constraints, and/or semantic interpretations that can be used to serialize information content.

Term: profile

A profile is a set of structural constraints and/or semantic interpretations that can apply to information content in addition to constraints and interpretations mandated by a media type.

Term: profile definition

A profile definition is a document that describes a profile's constraints and interpretations in a human-readable and/or machine-processable way.

Examples

media type

  • application/json
  • text/xml
  • text/turtle
  • application/trig

profile

The examples below are fictitious.

  • urn:example:schema-org-book (= uses the Schema.org ontology for books, can apply to HTML and RDF documents)
  • urn:example:main-title (= has a "title" element as child of the root with a text value, can apply to XML and JSON documents)
  • urn:example:dcat-xyz (= conforms to the DCAT profile XYZ)

Note how multiple profiles can apply to the same resource. For instance, both schema-org-book and main-title could apply to a JSON-LD document.

profile definition

The examples below are fictitious.

  • an HTML document describing urn:example:schema-org-book
  • an RDF document describing urn:example:schema-org-book

Possible implementation

A possible concrete implementation of the above is as follows:

  • Profiles are identified by an IRI—specifically, an HTTP URL
  • Dereferencing that HTTP URL leads to a profile definition document (with content negotiation)
  • Any given representation of a resource on the Web can conform to zero or more profiles (in addition to a media type)

Comments

  • (kcoyle) - At the moment, I'm not aware of anyone producing "atomistic" profiles, such as "main-title" or even "schema-org-book". Profiles that I know of describe an entire metadata "record" or usage. I'm not sure what the actual data would be behind these fragments, but I think it would be interesting to explore. The use case does need some explanation of the data that is being described. Karen Coyle (talk) 15:58, 17 December 2017 (UTC)
    • (Ruben) Indeed, the notion of profile here, for content negotiation purposes, is broader than the definition of an application profile (and I personally don't have a strong opinion on what the latter should be). The relevant use case for this is ID3. The idea is to resolve the problem that media types are one-dimensional. For instance, in the JSON world, HAL has its own media type, but essentially means that it is a JSON file with a _links element. One the other hand, Activity Streams has a application/activity+json MIME type. Allowing to specify that a response conforms to multiple profiles lets a server say that something is an activity stream that also conforms to HAL. Think of it as an HTML with multiple content boxes (the main content, navigation, sidebars, footer), and we can capture all of the assumptions a client can make about the document. Of course, this also allows for the simple case where the document conforms to just one profile.
      • (kcoyle) Ruben, to me application/hal+json is about structure, but not content. The Profile Negotiation document defines profile as: "The choice of the term "profile"was derived from the term "Application Profile" which the Dublin Core community defines as "schemas which consist of data elements drawn from one or more namespaces, combined together by implementors, and optimised for a particular local application". You seem to be using a different definition of profile from this. Am I correct in concluding that? Which brings up the question of the relationship between the profile negotiation document and the DCAT deliverable, if any. Karen Coyle (talk) 19:30, 7 January 2018 (UTC)
        • (LarsG) Karen, Ruben, My impression is that you roughly talk about the same thing. As I see it, a profile definition can range from very simple (titleProfile = "MUST have a title element") to extremely complex (mandatory and optional elements, cardinalities, etc.). One of the main points to me is that a profile definition can build on other profile definitions, e. g. documentProfile = titleProfile + mandatory author name, or academicPublicationProfile = titleProfile + abstractProfile where abstractProfile = "MUST have an abstract element". And yes Karen, you ar right that the definition we use in the I-D is different from what Ruben is suggesting, that's why we say that we probably need to re-write the I-D from scratch... Regarding application/hal+json, it's hard to tell from the specification if it's structure or content. The answer might be in the media type registration draft that I couldn't find on IETF. --Lars G. Svensson (talk) 11:26, 9 January 2018 (UTC)
  • (agbeltran, Alejandra) Am I right to think that media type is simply a MIME type (https://en.wikipedia.org/wiki/Media_type) as usual? Or are you trying to provide a different definition? Thanks
    • (Ruben) Same thing indeed.

kcoyle

Term: profile

Any document or file that describes the structure and content of a set of data. This document may be machine actionable or not (as in a PDF) in relation to programs that are processing the document. Some examples would be:

  1. The current DCAT-AP documents
  2. The Library of Congress MARC website with over 100 pages of documentation
  3. If the Guidelines that we develop describe machine-actionable profiles, then profiles that conform to the Guidelines would be also considered profiles by this definition
  4. (Possibly) an XML schema, a SHACL document

The purposes of profiles include:

  1. To document the structure of a particular set of data for the primary users of that data
  2. To facilitate data sharing by giving new or casual users enough information so that they can successfully make their own use of the data

Term: application profile

Application profiles (APs) are profiles designed to be used by some definable set of applications. APs should be machine actionable and probably will provide, as a minimum:

  1. the data elements in the data set they describe
  2. if relevant, some basic rules for cardinality, validation of values
  3. human-readable labels and instructions that describe the meaning and usage of data in the data set

Application profiles fulfill some of the same functions as XML schemas, SHACL or ShEx validation documents. They differ from these in that the emphasis is on describing the data set's structure and semantics both for machines and for humans.

Term: metadata application profile

Some data providers consider their data "metadata" and use that term for their application profiles. I think that this is the same as an application profile, but there is no reason to discourage this term if that's what is meaningful to some.

Comments

  • Karen, could you please expand a bit on why you think that the current DCAT-AP documents are profiles but not application profiles? I'd definitely say that they are "designed to be used by some definable set of applications" (e. g. the European data portals). --Lars G. Svensson (talk) 11:26, 9 January 2018 (UTC)
    • Lars, it's mainly that I was making the distinction that APs are machine-actionable. That may not be a distinction that folks agree on, but it seems to me that actionable profiles are signficantly different from documents describing a practice but that must be interpreted by humans and "re-coded" for use. There isn't a way to accurately test documentation, but presumably a machine-actionable profile could be directly coded (or natively coded) in SHACL or ShEx and could be subject to testing. Karen Coyle (talk) 15:25, 9 January 2018 (UTC)
      • Karen, OK, so what you call "application profile" would be what I call "schema" (as in XML Schema, JSON Schema and -- considering that RDF Shapes probably would have been named "RDF Schema" if that name hadn't been taken already -- RDF Shapes). I vaguely remember that this distinction has been discussed before (possibly without resolution) and that we also discussed the need for a standardised way to link a human-readable profile description page to a machine-processable schema. --Lars G. Svensson (talk) 15:38, 9 January 2018 (UTC)
  • here

Rob Atkinson

Term: profile

Strictly ISO interpretation of a "conforming subset" of one or more base specifications. (This is the way OGC uses the term profile, though there is some confusion typically about "extensions" - however in reality most extensions are really type-narrowing of allowable property ranges which has more model, but is still a valid subset. Note that also a specification may be considered a "null profile" - with an empty set of additional constraints, which means we only ever need to worry about profile conformance - and not create extra detail about specification conformance and confusion for the user about what is a profile and what is a specification. (This is important because some things currently described as specifications are actually conformant profiles of other specifications).

Consistent with Rubens definition a "set of structural constraints and/or semantic interpretations", a profile will consist of a set of "profile implementation specifications", which may include documents and executable fragments specifying some aspects of a profile.

Term: application profile

synonomous with "profile"

Term: profile implementation specification

A document that specifies some aspect of implementation of a profile. This may be a human readable document describing the entire profile, or a machine readable document describing a specific aspect that can be tested with a specific platform. A profile specification will thus require references to these resources and metadata describing their nature and purpose.

Comments

  • You truncated the ISO definition, which says: "... of one or more base specifications used to provide specific functions." Could you address whether that would change your definition? Karen Coyle (talk) 16:36, 5 January 2018 (UTC)
  • To me it looks as if your term "profile implementation specification" is the same thing as Ruben's "profile definition". Is that correct? If so we probably only have to agree on which term to use. --Lars G. Svensson (talk) 11:26, 9 January 2018 (UTC)

Definitions background information

ISO/IEC TR 10000-1

"3.1.4 Profile: A set of one or more base standards and/or ISPs,[International Standardized Profile] and, where applicable, the identification of chosen classes, conforming subsets, options and parameters of those base standards, or ISPs necessary to accomplish a particular function."

6. Concept of a Profile

"The concept of a profile, which fulfils the purposes defined in clause 5, is considered first in an abstract sense, with particular emphasis on the significance of the claim of conformance to a profile. This concept of an individual profile is then extended to include defining its relationship to other profiles, i.e. the concept of a taxonomy of profiles, and its place within it. Finally, since a profile has to have a concrete existence in order for it to be used effectively, these conceptual aspects are related to a formal documentation scheme."

...

"Profiles are related to Base Standards, to Registration Mechanisms, and to Conformance Tests of the IT systems which implement them."

ISO/TC 46/SC11N800R1: Where to start on creating a metadata schema

  • Metadata standard. A high level document which includes principles and implementation issues
  • Metadata schema. This document uses “schema” in same way as ISO 23081. “A schema is a logical plan showing the relationships between metadata elements, normally through establishing rules for the use and management of metadata specifically as regards the semantics, the syntax and the optionality (obligation level) of values.” Also referred to as an element set.
  • Application profile. “ An application profile delineates the use of me tadata elements declared in an element set. While an element set establishes concepts, as expressed via metadata elements, and focuses on the semantics or meanings of those elements, an application profile goes further and adds business rules and guidelines on the use of the elements. It identifies element obligations and constraints, and provides comments and examples to assist in the understanding of the elements. Application profiles may include elements integrated from one or more element sets thus allowing a given application to meet its functional requirements.”
  • Encoding scheme “Controlled list of all the ac ceptable values in natural language and/or as a syntax-encoded text st ring designed for machine processing.” Includes rules/formats for entering data such as dates, names of people, etc.

Dublin Core

The term profile is widely used to refer to a document that describes how standards or specifications are deployed to support the requirements of a particular application, function, community, or context. In the metadata community, the term _application profile_has been applied to describe the tailoring of standards for specific applications.

The Singapore Framework for Dublin Core Application Profiles is a framework for designing metadata applications for maximum interoperability and for documenting such applications for maximum reusability. The framework defines a set of descriptive components that are necessary or useful for documenting an Application Profile and describes how how these documentary standards relate to standard domain models and Semantic Web foundation standards. The framework forms a basis for reviewing Application Profiles for documentary completeness and for conformance with Web-architectural principles.

http://dublincore.org/documents/singapore-framework/

DCAT-AP

An Application Profile is a specification that re-uses terms from one or more base standards, adding more specificity by identifying mandatory, recommended and optional elements to be used for a particular application, as well as recommendations for controlled vocabularies to be used.

Source: the DCAT-AP v1.1. document available from https://joinup.ec.europa.eu/catalogue/distribution/dcat-ap-version-11

IMS Global

Application Profile A description of the use of a single technical specification to meet the needs of a particular community.


2.1 What is Application Profiling? Within the IMS context, Application Profiling is the tailoring of specification (by amending the binding of the specification) to suit the needs for its application to a particular community.1 For the purposes of this discussion, the source schema is the original schema being profiled, whilst the derived schema is the output of the profiling activity. This process may include one or more of the following actions to generate a derived schema:

Selection of a core sub-set of elements and fields from the source schema (expressed perhaps as a mandated sub-set which must be supported as a minimum); The addition of elements and/or fields (normally termed extensions) in a prescribed manner, to the source schema, thus generating the derived schema; Substitution of a vocabulary with a new, or extended vocabulary to reflect terms in common usage within the target community, e.g., a bounded set of competencies or a curriculum model; A comprehensive description of the semantics and common usage of the schema and constituent terms as they are to be applied across the community. Thus, Application Profiling can be summarized as:

Localization - the specialization of one or more conceptual data schemas (source schemas) to the precise needs of a community, generating a derived schema; Representation - mapping the localized conceptual schema(s) to a generic binding for interchange; Transaction - define how the abstract interface and service model, i.e., the APIs, and implied/stated transactions are to be realized utilizing a concrete platform technology. Some key reasons for developing an Application Profile include:

To meet technical and other requirements and preferences specific to a project, community, domain, or region; To address ambiguity and generality in a specification or standard; To foster semantic interoperability, e.g., through the use of commonly understood vocabularies; To facilitate testing for conformance and successful interoperability.

https://www.imsglobal.org/ap/apv1p0/imsap_oviewv1p0.html

ISO/IEC 10000-1

ISO/IEC 10000-1:1998 Information technology -- Framework and taxonomy of International Standardized Profiles -- Part 1: General principles and documentation framework provides an extensive discussion of this issue, framed as a general problem in standardization. From the introduction:

"Profiles, which define conforming subsets or combinations of base standards used to provide specific functions. Profiles identify the use of particular options available in the base standards, and provide a basis for the development of uniform, internationally recognized, conformance tests."

Here are the definitions from Clause 3:

3 Definitions

For the purposes of this part of ISO/IEC TR 10000, the following definitions apply.

3.1 Terms defined in this part of ISO/IEC TR 10000

3.1.1 Base Standard: An approved International Standard or ITU-T Recommendation.

3.1.2 International Standardized Profile: An internationally agreed-to, harmonized document which describes one or more profiles.

3.1.3 IT System: A set of IT resources providing services at one or more interfaces.

3.1.4 Profile: A set of one or more base standards and/or ISPs, and, where applicable, the identification of chosen classes, conforming subsets, options and parameters of those base standards, or ISPs necessary to accomplish a particular function. NOTE - ISPs may contain normative references to specifications other than International Standards; see document JTC 1 N 4047: The Normative Referencing of Specifications other than International Standards in JTC 1 International Standardized Profiles - Guidelines for ISP Submitters .

3.1.5 Taxonomy: A classification scheme for referencing profiles or sets of profiles unambiguously.

3.2 Terms defined in ISO/IEC TR 14252 The following terms are defined in ISO/IEC TR 14252:1996, Information technology — Guide to the POSIX Open System Environment (OSE) , and are included here for convenience.

3.2.1 Interoperability: The ability of two or more IT systems to exchange information and to make mutual use of the information that has been exchanged.

3.2.2 Open System Environment: The comprehensive set of interfaces, services, and supporting formats, plus user aspects, for interoperability and/or portability of applications, data, or people, as specified by information technology standards and profiles.

3.3 Conformance Terminology This part of ISO/IEC TR 10000 uses the following term related to conformance:

3.3.1 Implementation Conformance Statement [ICS]: A statement made by the supplier of an implementation or IT system claimed to conform to one or more specifications, stating which capabilities have been implemented, specifically including the relevant optional capabilities and limits. NOTE - The ICS can take several forms (e.g. in OSI it can be a profile ICS, protocol ICS, information object ICS or profile specific ICS, as defined in ITU-T Rec. X.290 | ISO/IEC 9646-1, and in POSIX it is a POSIX Conformance Document as defined in ISO/IEC 13210:1994).

The link above is to a free download.

OHIOLINK Digital Media Center

(goals)

  1. improve retrieval accuracy and resource discovery
  2. . facilitate multi-institutional interoperability and quality control
  3. . comply with the Open Archives Initiative Protocol for Metadata Harvesting
  4. enable collection migration, import & export between the DMC and other systems as necessary.

https://silver.ohiolink.edu/dms/dmccontribution/DMC_AP.pdf

Open Geospatial Consortium

OGC draws on a definition of profiles from ISO 19106

The ISO definition is :

profile Set of one or more base standards and - where applicable - the identification of chosen clauses, classes, subsets, options and parameters of those base standards that are necessary for accomplishing a particular function [ISO 19101, ISO 19106]

Internally there is some debate about the exact interpretation of restriction and extension - but the ISO definition implies profiles are a declaration of functional substitutability.

There are a range of profiles described here: http://www.opengeospatial.org/docs/profile

but there are more - (RobA will explore and see if the list can be updated.)


http://portal.opengeospatial.org/files/?artifact_id=16936

CEN Workshop

In practice, application profiles are created for a wide range of purposes: to document the semantics and constraints used for a set of metadata records (“instance metadata”); to help communities of implementers harmonize metadata practice among themselves; to identify emerging semantics as possible candidates for formal standardization; as guides for semantic crosswalks and format conversions; as specifications for formal encoding structures such as Document Type Definitions (DTDs); for interpreting or presenting legacy or proprietary metadata in terms of widely-understood standards; or for documenting the rules and criteria according to which a set of metadata was created. Application profiles often represent “work in progress”, providing foci for ongoing efforts to incrementally improve and clarify a body of shared metadata semantics within a particular user community.

ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/MMI-DC/cwa14855-00-2003-Nov.pdf


ARIADNE

Profile definition: "We define application profiles as schemas which consist of data elements drawn from one or more namespaces, combined together by implementors, and optimised for a particular local application."

http://www.ariadne.ac.uk/Issue25/App-Profiles/

ODRL

3. ODRL Profiles 3.1 ODRL Profile Purpose

The ODRL Information Model serves as the core framework and vocabulary to express policies. The ODRL Core Vocabulary [odrl-vocab] articulates this set of vocabulary terms. An ODRL policy may be expressed using the ODRL Core Vocabulary, and this represents the minimally supported policy expression.

An ODRL Profile MUST be defined to provide vocabulary terms (as scoped in the ODRL Profile Mechanism section) that can be used in ODRL policies requiring additional semantics. An ODRL Profile explicitly serves community needs by specifying the vocabulary terms they require to be supported in ODRL policy expressions. These terms may be defined explicitly or may be adopted from the ODRL Common Vocabulary.

The ODRL Common Vocabulary [odrl-vocab] provides a generic range of common actions for Permissions, Prohibition, and Duties as well as Policy subclasses, Constraint left operands and operators, Asset relations, and Party functions.

https://www.w3.org/TR/odrl-model/#profilerelations, and Party functions.

Examples of Application Profiles, Metadata Application Profiles

DCAT Application Profiles

Analysis of DCAT Application Profiles

See spreadsheet [[3]]


Reference documentation

For background information about APs in Dublin Core, see Karen's mail

Retrieved from "https://www.w3.org/2017/dxwg/wiki/index.php?title=ProfileContext&oldid=2955"