The Profiles Ontology

W3C First Public Working Draft

This version:
https://www.w3.org/TR/2018/WD-dx-prof-20181218/
Latest published version:
https://www.w3.org/TR/dx-prof/
Latest editor's draft:
https://w3c.github.io/dxwg/profilesont/
Test suite:
https://github.com/CSIRO-enviro-informatics/prof-ont-implementation-results
Implementation report:
https://github.com/CSIRO-enviro-informatics/prof-ont-implementation-results
Editors:
Rob Atkinson (Metalinkage, Open Geospatial Consortium)
Nicholas J. Car (CSIRO)
Participate:
GitHub w3c/dxwg
File a bug
Commit history
Pull requests
Contributors:
Simon Cox

Abstract

The Profiles Ontology is an RDF vocabulary to describe profiles of (one or more) standards for information resources. It describes the general pattern of narrowing the scope of a specification with additional, but consistent, constraints, and is particularly relevant to data exchange situations where conformance to such profiles is expected and carries additional context. The Profiles Ontology enables profile descriptions to specify the role of resources related to data exchange such as schemas, ontologies, rules about use of controlled vocabularies, validation tools, and guidelines. The ontology may however be used to describe the role of artifacts in any situation where constraints are made on a the usage of more general specifications. The namespace for PROF terms is defined in Section 3: Namespaces, and the vocabulary terms in Section 7: Vocabulary Specification.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Dataset Exchange Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation.

GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to public-dxwg-comments@w3.org (archives).

Please see the Working Group's implementation report.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 February 2018 W3C Process Document.

Overview of DXWG documents on profiles

This document is part of a set of documents on profiles, edited by the W3C Dataset Exchange Working Group (DXWG). Some of the documents are general while some are technology-specific:

1. Introduction

This section is non-normative.

This Profiles Ontology provides a structure to describe profiles of information standards. Its development was triggered by the appearance of multiple profiles of the Dataset Catalog Vocabulary (DCAT) [VOCAB-DCAT-20140116] and examples of profiles including the Dublin Core Application Profiles guidelines [DCAP] and various profiles of OpenGeospatial Consortium specifications.

The Profiles Ontology is an RDF vocabulary to describe the resources that define and implement a profile. A profile is defined as "A named set of constraints on one or more identified base specifications or other profiles, 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." These resources may be human-readable documents (PDFs, textual documents), vocabularies or ontologies (XSD, RDF), resources specific to validation tools (SHACL, ShEx, Schematron), or any other files or resources that support the profile. Each resource is defined as having a role that defines its function within the profile.

This ontology also provides for the description of relationships between such profiles and the standards to which they conform. A standard in this case can be a vocabulary or it can be another profile from which the described profile is a derivation, expansion, or selection. This ontology provides a standardized, machine readable formalism for describing the context of profiles. The basis of the ontology is a specialization of dct:Standard, allowing the use of the dct:conformsTo predicate to specify conformance to a profile.

A "profile" here is represented by the Profile class definition in the Vocabulary Specification with the following definition: "A named set of constraints on one or more identified base specifications or other profiles, 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."

Profiles aim to increase interoperability within a community of users by introducing certain constraints on the use of a more general standard such as a published vocabulary. Such constraints include restrictions on the cardinality of certain properties, or a requirement to select values of a property from a specified controlled vocabulary. Profiles have generally been specified through textually-oriented documents, and/or platform specific constraint languages.

A vocabulary of Resource Roles is provided alongside this ontology and that list is extensible.

Issue 536: Link to the Resource Roles vocab in the Profiles Ont docprofile-description

Currently the Resource Roles vocab is referenced in the Prof Ont doc (see last para https://w3c.github.io/dxwg/profilesont/#introduction) but no actual link is given. PR 532 brings the Resource Roles vocab into W3C styling and updates it so now a link to that doc needs to be added.

The reason for this whole issue here is that how it is referenced needs discussion. If it is to be a NOTE, how will this impact future re-publication of it as a dynamic vocab, not a static document?

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

For the purpose of compliance, the normative sections of this document are Section 6 Conceptual Model, Section 7 Vocabulary Specification & Section 9 Test Suite.

2.1 Notational Conventions

The key words may, must, must not, optional, shall, shall not, should, should not, recommended, required, in this document are to be interpreted as described in [RFC2119].

3. Namespaces

The namespace for PROF is http://www.w3.org/ns/dx/prof/. However, it should be noted that PROF makes use of terms from other vocabularies, in particular Dublin Core [DCTERMS]. PROF itself only defines a minimal set of classes and properties of its own.

A full set of namespaces and prefixes used in this document is shown in the table below.

PrefixNamespace
dcathttp://www.w3.org/ns/dcat#
dcthttp://purl.org/dc/terms/
owlhttp://www.w3.org/2002/07/owl#
profhttp://www.w3.org/ns/dx/prof/
provhttp://www.w3.org/ns/prov#
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfshttp://www.w3.org/2000/01/rdf-schema#
skoshttp://www.w3.org/2004/02/skos/core#
xsdhttp://www.w3.org/2001/XMLSchema#
(others)All other namespace prefixes are used in examples only.
In particular, IRIs starting with "http://example.com" represent some application-dependent IRI [RFC3987]
Issue 398: Determine final namespaceprofile-description

This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

4. Motivation

This section is non-normative.

Until this ontology, there was no formal W3C method for describing the objects (Internet resources) related to profiles.

There are a multitude of ways to describe the components needed to define a profile and support validation of instances, such as:

Describing only the components within a profile via documents or constraint languages does not indicate many things either important or interesting to know about a profile such as:

With a mechanism to relate profiles to standards and other profiles, profile hierarchies can be established which will:

Issue 551: Harmonise Ont/Conneg references and contentprofile-descriptionprofile-negotiation

The last part of the motivation section of the prof-ont document refers to machine interpretation of profiles and how the ontology could help in conneg with fallback options (e.g. retrieving a more generic version of a requested resource, which the server could not deliver, based on a profile link). Then, a note points to the prof-conneg document. However, the prof-conneg document doesn't include these fallback options based on the ontology yet.

Note: See the Content Negotiation by Profile document
The details of profile negotiation using this ontology, as suggested immediately above, and other methods, are explained in detail in the related [PROF-CONNEG] document.

This section is non-normative.

Issue 400: Reference DC Singapore Frameworkprofile-description

This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

PROV deals with derivation and a large part of PROF is derivation and relation

Issue 403: Reference OGC ModSpecprofile-description

This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

Refer to OGC Modular Specification policy [[modspec]] and related work in ISO TC/211 [[cfg-mgmt]].

These specifications define how dependencies between 'standards' can be handled in a manageable way.

6. Conceptual Model

Ontology overview diagram
Figure 1 OWL [OWL2-OVERVIEW] overview diagram of this ontology

The model takes the dct:Standard Class as a starting point and defines two specializations, a Base Specification (a Standard that does not profile anything) or a Profile (a Standard which does). Base Specifications or Profiles can have Resource Descriptors associated with them that define rules for implementation, provide guidance on how to implement, or some other role. Resource Descriptors must indicate the role they play (to guide, to validate etc.), the formalism they adhere to (dct:format) and any dct:Standard that they themselves conform to (dct:conformsTo).

A vocabulary of Resource Roles is provided alongside this ontology and that list is extensible.

7. Vocabulary Specification

Issue 406: Complete the information transfer from previous HTML docdue for closingprofile-description

This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

7.1 RDF representation

The PROF vocabulary is available in RDF. Alongside the primary artifact, there is a set of other RDF files that provide additional information, including:

  1. alignments to other vocabularies, some of which are normative, and others which are for guidance only
  2. additional axioms, which can be useful in some contexts
  3. validating graphs using [SHACL]

These other artifacts are linked to throughout this document.

7.2 Dependencies

This vocabulary makes use of [DCTERMS] properties conformsTo & format in its normative specification.

7.3 Class: BaseSpecification

OWL Class:prof:BaseSpecification
Label:Base Specification
Definition:A specification that defines all implementation constraints, without applying constraints on usage of another specification
Sub class of:prof:Profile
Usage note:This may not be a useful class: documents of any specification can be regarded as a trivial profile, so applications only need to be concerned with Profile conformance. If used, a Base Specification may not have the property prof:isProfileOf.

7.4 Class: Profile

OWL Class:prof:Profile
Label:Profile
Definition:

A named set of constraints on one or more identified base specifications or other profiles, 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.

This definition includes what are often called "application profiles", "metadata application profiles", or "metadata profiles".

Sub class of:dct:Standard
Source:https://www.w3.org/2017/dxwg/wiki/ProfileContext

7.4.1 hasProfile

RDF Property:prof:hasProfile
OWL type:owl:ObjectProperty
Label:has profile
Definition:A dct:Standard (or a Profile or Base Specification) has a Profile
Domain:dct:Standard
Range:prof:Profile
Inverse of:prof:isProfileOf

7.4.2 hasResource

RDF Property:prof:hasResource
OWL type:owl:ObjectProperty
Label:has resource
Definition:A Profile has a Resource Descriptor
Range:prof:ResourceDescriptor

7.4.3 isProfileOf

RDF Property:prof:isProfileOf
OWL type:owl:ObjectProperty
Label:is profile of
Definition:A Profile is a profile of a dct:Standard (or a Base Specification or another Profile)
Domain:prof:Profile
Range:dct:Standard
Inverse of:prof:hasProfile
Usage note:The semantics of the rdfs:Range means that any resource treated as a base specification can be regarded as a Profile (i.e. may be any specification with an empty set of additional constraints)

7.4.4 isTransitiveProfileOf

RDF Property:prof:isTransitiveProfileOf
OWL type:owl:ObjectProperty
Label:is a transitive profile of
Definition:A dct:Standard (or a Base Specification or another Profile) that a Profile conforms to transitively (through an intermediary)
Domain:prof:Profile
Range:dct:Standard
Usage note:A means to list all the Profiles/Standards within a transitive profile hierarchy
Issue 520: Illustrate transitivity with diagramsdue for closingprofile-description

To further spell out that PROF provides for a profile transitivity patterns and what the pattern is, we could quote the transitivity illustration from SKOS https://www.w3.org/TR/skos-primer/#sectransitivebroader in the PROF ont doc.

We then need to indicate that while PROF provides the pattern, it doesn't provide the mechanics and explanation of specific situation results (inference results).

Note: Explanation of profiling transitivity

The property prof:isTransitiveProfileOf defined here performs a role similar to that of the property skos:broaderTransitive defined in [SKOS-REFERENCE]. That property "...allows communities of practice to exploit transitive interpretations of hierarchical networks..." while freeing the simpler hierarchy property of skos:broader from having to enforce transitivity which would prevent broader but non-transitive relationships.

Figure 4.5.2 from [SKOS-PRIMER], reproduced below, illustrates the general principle of use of skos:broaderTransitive.

Figure 2 Inferring a transitive hierarchy from asserted skos:broader statements. Dotted arrows represent statements inferred from the SKOS data model. Solid arrows represent asserted statements. Reproduction of Figure 4.5.2 in [SKOS-PRIMER]

This ontology defines prof:isTransitiveProfileOf to allow for the transitive interpretations of hierarchies of Profiles (of other Profiles and Standards) while freeing the simpler property, prof:isProfileOf from having to enforce transitivity.

While this ontology provides this prof:isProfileOf & prof:isTransitiveProfileOf pair of properties, it does not specify how a particular implementation of a Profile that is related to another Profile or Standard by prof:isTransitiveProfileOf should implement specific inferences.

Inference based on prof:isTransitiveProfileOf will be more complex than inference based on skos:broaderTransitive due to Profiles being complex objects relative to SKOS Concepts.

7.4.5 hasToken

RDF Property:prof:hasToken
OWL type:owl:DatatypeProperty
Label:has token
Definition:A property for identifying this Profile for use in APIs
Domain:prof:Profile
Range:xsd:token
Usage note:This property is to be used to indicate a token that identifies this Profile which should be used when the Profile's URI cannot be used. For potential use in content negotiation
Issue 453: Consider use of adms:identifier instead of prof:tokenprofile-description

7.5 Class: ResourceDescriptor

The Resource Descriptor class' name may not convey its intention well. This name needs to be reconsidered with discussion about it here.

OWL Class:prof:ResourceDescriptor
Label:Resource Descriptor
Definition:A resource that defines an aspect - a particular part or feature - of a Profile
Usage note:Used to indicate the formalism (via dct:format) and any adherence to a dct:Standard (via dct:conformsTo) to allow for machine mediation as well as its purpose via relation to a ResourceRole (via hasRole)

7.5.1 hasArtifact

RDF Property:prof:hasArtifact
Label:has artifact (resource)
Definition:An rdfs:Resource that implements the Resource Descriptor
Domain:prof:ResourceDescriptor
Usage Note:A property to link from a Resource Descriptor to an actual resource (rdfs:Resource; an individual) that implements it

7.5.2 dct:conformsTo

This property's details are from the [DCTERMS] specification.

RDF Property:dct:conformsTo
Label:Conforms To
Definition:An established standard to which the described resource conforms
Sub property of:dc:relation, dct:relation

7.5.3 dct:format

This property's details are from the [DCTERMS] specification.

RDF Property:dct:format
Label:Format
Definition:The file format, physical medium, or dimensions of the resource
Sub property of:dc:format

7.5.4 hasRole

RDF Property:prof:hasRole
Label:has role
Definition:Functional role of a Resource
Domain:prof:ResourceDescriptor
Range:skos:Concept
Usage note:Some roles are published alongside this ontology in a separate vocabulary

7.5.5 isInheritedFrom

RDF Property:prof:isInheritedFrom
Label:is inherited from
Definition:A Profile's Resource Descriptor has been inherited from a Base Specification
Domain:prof:ResourceDescriptor
Range:prof:Profile
Usage note:Profiles within inheritance hierarchies may use this property. If absent, then the Resource Descriptor applies specifically to this Profiles only

7.6 Class: ResourceRole

OWL Class:prof:ResourceRole
Label:Resource Role
Definition:The role that an Resource plays
Sub class of:skos:Concept
Usage note:Specific terms must come from a vocabulary
Issue 452: Determine how to reference ResourceRole vocabprofile-description

Alongside the Profiles Ontology a vocabulary of ResourceRole instances has been made (see the RDF file however the way this is referenced from the Profiles Ont doc has not yet been determined.

8. Examples

This section is non-normative.

This section contains a few modelled examples of existing profiles to demonstrate aspects of this ontology. While efforts have been made to ensure they are accurate at the time of this document's publication, they are not to be considered authoritative; their purpose is only to illustrate this ontology's use.

8.1 DCAT-AP

This example showcases this ontology's description of parts of a profile.

DCAT-AP is the widely used European Application Profile of DCAT. DCAT-AP is described in document form (PDF & DOCX) and a constraints document for instance validation is available, formulated using the W3C's Shapes Constraints Language constraints language [SHACL].

The figure below described DCA-AP graphically, using elements from this ontology.

Figure 3 DCAT-AP described using this ontology

In words this ontology's descriptions of DCAT-AP is:

In RDF (turtle format), DCAT-AP is describe using the Profiles Ontology, with many properties not listed in the summary descriptions above as:

Example 1: DCAT-AP described using Profile Ontology in RDF (turtle)
<https://joinup.ec.europa.eu/release/dcat-ap-v11>
  a prof:Profile ;
  prof:hasToken "dcat-ap" ;
  rdfs:label "DCAT-AP" ;
  rdfs:comment "DCAT Application Profile for data portals in Europe" ;
  dc:publisher "European Union" ;
  prof:isProfileOf <http://www.w3.org/ns/dcat> ;
  # this profile has, itself profiles. Here GeoDCAT-AP is given
  prof:hasProfile <https://joinup.ec.europa.eu/release/geodcat-ap-v10> ;
  # SHACL constraints for the profile, guidance doc in Word & PDF & an image of the profile components
  prof:hasResource
    # Guidance doc in Word (DOCX)
    <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f6f27f059_bf785_b4d7d_bb602_b6448aab73bd5> ,
    # Guidance doc in PDF
    <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f17e18570_b1d77_b4171_b9df5_bb53cb4f017d4> ,
    # profile image (PNG)
    <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f1131a208_b92e9_b4427_ba40c_b6c47746cd422> ,
    # Constraints in SHACL  
    <https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f016d88c3_ba0b3_b4506_bae4e_b758e7401c096> ;
.

<https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f6f27f059_bf785_b4d7d_bb602_b6448aab73bd5>
  a prof:ResourceDescriptor;
	rdfs:label "DCAT-AP Guidance Document (Word)" ;
	dct:format <https://w3id.org/mediatype/application/msword> ;
	prof:hasRole roles:Guidance ;
.

<https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f17e18570_b1d77_b4171_b9df5_bb53cb4f017d4>
  a prof:ResourceDescriptor;
	rdfs:label "DCAT-AP Guidance Document (PDF)" ;
	dct:format <https://w3id.org/mediatype/application/pdf> ;
	prof:hasRole roles:Guidance ;
.

<https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f1131a208_b92e9_b4427_ba40c_b6c47746cd422>
  a prof:ResourceDescriptor;
	rdfs:label "DCAT-AP Image" ;
	dct:format <https://w3id.org/mediatype/image/png> ;
	prof:hasRole roles:Guidance ;
.
      
<https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f016d88c3_ba0b3_b4506_bae4e_b758e7401c096>
  a prof:ResourceDescriptor;
	rdfs:label "DCAT-AP Constraints" ;
	dct:conformsTo <http://www.w3.org/ns/shacl>; # the namespace for SHACL
	dct:format "text/turtle" ;
	prof:hasRole roles:ConformanceTest ;
.

8.2 DCAT-AP hierarchy

This example showcases this ontology being used to indicated profiles within a complex hierarchy.

Figure 4 DCAT-AP and related profiles in a hierarchy

DCAT-AP, a profile of DCAT, has itself been profiled for various European countries, such as Belgium who has issued DCAT-BE. Additionally, there are several domain profiles of DCAT-AP, such as GeoDCAT-AP - for describing geospatial datasets, dataset series and services - and StatDCAT-AP for enhancing interoperability between descriptions of statistical datasets. further to this, there is even an Italian profile of GeoDCAT, DCAT-AP-IT.

This profile hierarchy is represented graphically in the figure above and in RDF (turtle) below.

Example 2: The GeoDCAT profile hierarchy described using Profile Ontology in RDF (turtle)
<http://www.w3.org/ns/dcat>
  a prof:BaseSpecification ;

<https://joinup.ec.europa.eu/release/dcat-ap-v11>
  a prof:Profile ;
  rdfs:label "DCAT-AP" ;
  prof:isProfileOf <http://www.w3.org/ns/dcat> ;

<http://dcat.be>
  a prof:Profile ;
  rdfs:label "DCAT-BE" ;
  prof:isProfileOf <https://joinup.ec.europa.eu/release/dcat-ap-v11> ;

<https://joinup.ec.europa.eu/release/geodcat-ap-v10>
  a prof:Profile ;
  rdfs:label "GeoDCAT-AP" ;
  prof:isProfileOf <https://joinup.ec.europa.eu/release/dcat-ap-v11> ;

<https://joinup.ec.europa.eu/solution/statdcat-application-profile-data-portals-europ>
  a prof:Profile ;
  rdfs:label "StatDCAT-AP" ;
  prof:isProfileOf <https://joinup.ec.europa.eu/release/dcat-ap-v11> ;

<https://joinup.ec.europa.eu/news/geodcat-apit1>
  a prof:Profile ;
  rdfs:label "GeoDCAT-AP-IT" ;
  prof:isProfileOf <https://joinup.ec.europa.eu/release/geodcat-ap-v10> ;

Since there are no restrictions on either the property prof:isProfileOf or the class definition of prof:Profile that prevent them from being used to represent polyhierarchies, Belgium could release a profile of [StatDCAT-AP] (e.g., StatDCAT-BE), that would be both a profile of DCAT-BE and [StatDCAT-AP]. This imagined profile, '?' in the figure above, would not be a profile of GeoDCAT-AP.

9. Test Suite

A software suite is made available to test implementations of this ontology for compliance. This suite comprises of [SHACL] RDF graph validation templates and instructions for the application of those templates to implementations.

Issue 407: Prof Ont Test Suite toolsprofile-description

This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

10. Implementations

This section is non-normative.

Implementation conformance reports for this ontology are given in:

Issue 467: Model implementation reporting as done in SHACLprofile-descriptionprofile-negotiation

The SHACL Recommendation contains a link to an SHACL Test Suite and Implementation Report that we should emulate to implementations.

Issue 409: Seek a second profiles implementationprofile-description

This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

11. Alignments

This section is non-normative.

This section will list alignments from PROF to other W3C ontologies.

11.1 Alignment with DCAT

This ontology aligns with the Dataset Catalogue vocabulary as per the class and property diagrams below.

The RDF file giving the formal alignment is avauilable here: profilesont_dcat_alignment.ttl.

Alignment of PROF classes with DCAT 1.1 classes
Figure 5 Alignment of PROF classes with DCAT 1.1 [VOCAB-DCAT-2-20180508] classes. PROF classes are indicated with their rdfs:label text and no namespace prefix.
Alignment of PROF properties with DCAT 1.1 properties
Figure 6 Alignment of PROF classes with DCAT 1.1 [VOCAB-DCAT-2-20180508] properties. PROF properties are indicated with their rdfs:label text and no namespace prefix.

The following table summarieses the mappings shown graphically in Fig. 2 & 3.

PROF elementMapping propertyDCAT elementNotes
prof:hasResourcerdfs:subPropertyOfdcat:distribution
dct:conformsTo--Used similarly
dct:format--Used similarly
prof:hasRolerdfs:subClassOfdcat:Distribution
prof:Profilerdfs:subClassOfdcat:ResourceGeneric association

11.2 Alignment with ADMS

Issue 240: PROF - ADMS alignment

Draft added to the relevant wiki page ("Alignments and crosswalks").

@makxdekkers , could you please check it out, and see if anything needs to be changed? Thanks!

11.3 Alignment with VOAF

Prepare a formal alignment of PROF (Prof Desc Ont) to VOAF

11.4 Alignment with OGC/ISO Modular specification model

Issue 405: Complete PROF/x alignmentsprofile-description

This issue was created in the Profiles Ontology document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

12. Security and Privacy

This section is non-normative.

Issue 479: Profiles Ont doc Security and Privacyprofile-description

A. Appendices

A.1 Issue Summary

A.2 Requirements

This section lists, and then addresses, individual requirements that the Dataset Exchange Working Group considered important for content negotiation by profile.

Note

Responses to individual requirement Issues listed here are, at the time of the First Public Working Draft of this document, for demonstration only; to indicate the logic of answers to individual requirements.

These requirement responses may not survive in their current form in later drafts of this document nor may individual listings of requirements; they may be subsumed into the flowing txt of the document.

Entailment of schema.org [RES]

Define schema.org equivalents for DCAT properties to support entailment of schema.org compliant profiles of DCAT records.


Related use cases: Discoverability by mainstream search engines [ID40] 

RESPONSE FOR 65

Profile definition [RPFDF]

Create a sufficiently wide definition of an application profile to address declaration of interoperability profiles data may conform to, and through this mechanism provide the means for DCAT instances and collections to also declare the profiles of DCAT they conform to.

These Use case specific requirements apply to the required scope of this definition. Where appropriate these are also captured as additional requirements.

  1. Clarify any relationship between profiles and validation languages
  2. Profiles have URI identifiers that resolve to more detailed descriptions
  3. Each application profile needs to be documented, preferably by showing/reusing what is common across profiles
  4. Profiles should provide both machine and human readable views.
  5. Profiles may inherit clauses from one or more parent profiles
  6. Profiles must support a view that includes all inherited constraints clearly identifying the parent profile the constraint is defined in.
  7. Profiles may be used to describe the metadata standard a description conforms to, the standards to which the resource described (e.g. dataset) and the standards each distribution conforms to.
  8. Conceptually, profiles can extend other vocabularies or profiles, or can be refinements of other vocabularies or profiles (#ID37)
  9. Responses can conform to multiple, modular profiles (#ID3)


Related requirements: Profile representation [RPFRP] Profile negotiation [RPFN] Profiles listing [RPFL] 
Related use cases: Detailing and requesting additional constraints (profiles) beyond content types [ID2] Responses can conform to multiple, modular profiles [ID3] Discover available content profiles [ID5] Description of dataset compliance with standards [ID43] Profile relation to validation [ID48] 

RESPONSE FOR 72

Issue 204: Clarify any relationship between profiles and validation languages (6.1)f2f3profile-guidancerequirement

#75

RESPONSE FOR 204

Issue 205: Profiles have URI identifiers that resolve to more detailed descriptions (6.1)f2f3profile-guidancerequirement

#75

RESPONSE FOR 205

This is handled by having URIs for profiles resolve to HTML landing pages and RDF descriptions of the profile created according to this ontology which then lenk to Resource Descriptors and other Profiles.

Issue 207: Each application profile needs to be documented, preferably by showing/reusing what is common across profiles (6.8.1)f2f3profile-guidancerequirement

#75

RESPONSE FOR 207

This is addressed by a Profile using this ontology to link to other Profiles from which it derives.

Issue 208: Application profiles need a rich expression for the validation of metadata (6.1)f2f3profile-guidancerequirement

#75

RESPONSE FOR 208

This is addressed by Profiles using Resource Descriptors from this ontology which then implement constraint languages with various Roles such as "Full Constraints".

Issue 209: Profiles SHOULD have both both machine and human-readable views. (6.1)f2f3profile-guidancerequirement

#75

RESPONSE FOR 209

Issue 210: Profiles must support declaration of vocabulary constraints (6.1)f2f3profile-guidancerequirement

#75

RESPONSE FOR 210

This is addressed by a Profile implementing a constraint language via a Resource Descriptor and selecting an appropriate Resource Role for it.

Issue 211: Profiles should provide both machine and human readable views (6.1)f2f3profile-guidancerequirement

#75

RESPONSE FOR 211

Issue 212: Profiles may inherit clauses (modules, if designed for this type of reuse) from one or more parent profiles to optimize re-use of existing specifications (6.1)f2f3profile-guidancerequirement

#75

RESPONSE FOR 212

Issue 213: Profiles must support a view that includes all inherited constraints clearly identifying the parent profile the constraint is defined in (6.1)f2f3profile-guidancerequirement

#75

RESPONSE FOR 213

Issue 214: A mechanism must be available to identify conformance to each inherited profile given conformance to a profile that specialises it (6.1)f2f3profile-guidancerequirement

#75

RESPONSE FOR 214

Issue 215: Profiles describe conformance to metadata standards (6.1)f2f3profile-guidancerequirement

Profiles may be used to describe the metadata standard a description conforms to, the standards to which the resource described (e.g. dataset) and the standards each distribution conforms to (6.1)

#75

RESPONSE FOR 215

Profiles described using this ontology may indicate that they are a profileOf another Profile.

Issue 216: Profiles extend or refine (UC 5.37)f2f3profile-guidancerequirement

Profiles can extend other vocabularies or profiles, or can be refinements of other vocabularies or profiles (UC 5.37)

RESPONSE FOR 216

Issue 217: Responses can conform to multiple, modular profiles (UC 5.3)f2f3profile-guidanceprofile-negotiationrequirement

RESPONSE FOR 217

Issue 222: Profiles must support discoverability via search engines [ID40] (UC 5.40)f2f3profile-guidancerequirementrequires discussion

RESPONSE FOR 222

Issue 255: There needs to be a property in the profile where the rules for the descriptive content can be provided. This would apply to the entire profile. [ID42] (5.42)plenary-approvedprofile-guidancerequirement

This requirement is based on a use case that reflects practice primarily in libraries, but in some cases also in archives and museums.

For the last 50 years, libraries have used a specific data standard called "MARC".[1] That data standard includes a single data element to indicate the cataloging rules that were used to create the metadata. The element is called "descriptive cataloging form."[2]

18 - Descriptive cataloging form
x - Non-ISBD
a - AACR 2
c - ISBD punctuation omitted

A new data standard called BIBFRAME[3] includes this same information as one element of administrative data[4] for the bibliographic description (aka: record). The property is called "descriptive conventions":

Property: | descriptionConventions
Label: | Description conventions
Definition: | Rules used for the descriptive content of the resource description.
Used with: | AdminMetadata
Expected Value: | DescriptionConventions

In both cases, there is one value for each "record".

Note that the "conventions" or "rules" are in part (as Phil said) style guides, but also contain detailed instructions for making decisions. Many such decisions are not validatable, but must be left to the human cataloger to make a decision within her context, and there often is "no right answer". The current rules used by many Western libraries are over 1000 pages in length.[6] Unfortunately there isn't an open access version but I could supply examples (warning: they'd be lengthy) if anyone wishes.

[1] http://www.loc.gov/marc/bibliographic/
[2] http://www.loc.gov/marc/bibliographic/bdleader.html
[3] http://www.loc.gov/bibframe/docs/index.html
[4] http://id.loc.gov/ontologies/bibframe.html#c_AdminMetadata
[5] http://id.loc.gov/ontologies/bibframe.html#p_descriptionConventions
[6] https://www.amazon.com/RDA-Resource-Description-Print-2015-Revision/dp/0838913466/ref=sr_1_1?ie=UTF8&qid=1528843589&sr=8-1&keywords=resource+description+and+access

RESPONSE FOR 255

Issue 264: Metadata about server profile support can be used for discovery and mediated traversal via content negotiation. [ID5] (5.5)profile-guidanceprofile-negotiationrequirementrequires discussion

Entered from Google Doc

RESPONSE FOR 264

Issue 268: A profile can have multiple base specifications [ID37] (5.37)plenary-approvedprofile-guidancerequirement

Entered from Google Doc

RESPONSE FOR 268

Issue 272: A profile should have human-readable documentation that expresses for humans the main components of a profile, which can also be available as machine-readable resources (ontology or schema files, SHACL files, etc). This includes listing of elements in the profile, instructions and recommendations on how to use them, constraints that determine what data is valid according to the profile, etc. [ID37] (5.37)plenary-approvedprofile-guidancerequirementrequires discussion

Entered from Google Doc.

From the documents accessible from references in this use case, it should be possible to infer more specific requirements in terms of profile documentation, but I lack time. It could be captured by other cases. It should maybe be addressed at a later stage of DXWG work.

RESPONSE FOR 272

Issue 279: Profiles may be written in or may link to a document or schema in a validation language (ShEx, SHACL, XMLschema). [ID41] (5.41)plenary-approvedprofile-guidancerequirement

Entered from Google Doc

RESPONSE FOR 279

Using this ontology, a Profile may indicate a Resource Descriptor instance by way of the resource property. That Resource Descriptor may be a schema that conformsTo a constraints language, such as SHACL etc.

Issue 280: Profiles should be able to indicate which external specifications are expected to be applied/have been applied to values of individual properties [ID43] (5.43)plenary-approvedprofile-descriptionprofile-guidancerequirement

Entered from Google Doc

RESPONSE FOR 280

Issue 284: A profile must have an identifier that can be served with a response to an API or http request. [ID2] (5.2)plenary-approvedprofile-guidanceprofile-negotiationrequirementrequires discussion

Entered from Google Doc

Suggested re-wording: a profile must have an identifier

RESPONSE FOR 284

Using this ontology, all Profile instances are RDF Resources with their own URIs. Additionally, the token property is given for use with a Profile to be used to identify it where use of a full URI is not possible, such as within HTTP Query String Arguments.

Issue 286: There should be a way to look up additional information about a profile - this may be machine readable for run-time mediation or used to develop or configure a client [ID2] (5.2)plenary-approvedprofile-guidanceprofile-negotiationrequirementrequires discussion

Entered from Google Doc

What kinds of information? Can we clarify this?

RESPONSE FOR 286

Following relationships from a profile defined using this ontology, a person or machine may discover either Resource Descriptor resources describing any sort of document relevant to the profile or other Profiles.

Issue 287: A server can indicate that a response conforms to multiple profiles. [ID3] (5.3)due for closingplenary-approvedprofile-guidanceprofile-negotiationrequirementrequires discussion

Entered from Google Doc

Antoine suggests: “some data may conform to several profiles at once” and that we should remove modular.

RESPONSE FOR 287

Issue 288: Profiles offered by a service must be discoverable through a machine-readable graph of metadata that describes what is offered and how to invoke the offered profiles. [ID5] (5.5)plenary-approvedprofile-guidancerequirementrequires discussion

Entered from Google Doc

RESPONSE FOR 288

Graph navigation of profiles' information described using this ontology is supported by its RDF mechanics.

An instance of a resource claiming adherence to an instance of a Profile might indicate its adherence by using the dct:conformsTo property.

Issue 455: Provide an example of both a profile and a resource adhereing to itprofile-description

Currently we haven't actually articulated how a resource claiming to conform to a profile indicates that cliamed conformance. Is it by simple use of dct:conformsTo? If so, what's the pattern of going from a resource to the Profile it conforms to then to a Resource Descriptor with some sort of Constraints Resource Role so it can be tested?

A.3 Additional Issues

This section will be removed in a later version of this document.

Additional Issues related to this document and not yet placed within it are listed at the:

B. References

B.1 Normative references

[DCTERMS]
DCMI Metadata Terms. Dublin Core metadata initiative.14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dcmi-terms/
[PROF-CONNEG]
Content Negotiation by Profile. 2018-12-31. W3C Editor's Draft. URL: https://www.w3.org/TR/dx-prof-conneg
[PROF-GUIDANCE]
Profile Guidance. W3C Editor's Draft.
[PROF-IETF]
Negotiating Profiles in HTTP. L. Svensson; R. Verborgh.2017-10-24. IETF Internet Draft. URL: https://profilenegotiation.github.io/I-D-Accept--Schema/I-D-accept-schema
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987
[SHACL]
Shapes Constraint Language (SHACL). Holger Knublauch; Dimitris Kontokostas. W3C. 20 July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/

B.2 Informative references

[DCAP]
Guidelines for Dublin Core Application Profiles (Working Draft). Karen Coyle; Thomas Baker. 2009-05-18. DCMI Recommended Resource. URL: http://dublincore.org/documents/dcmi-terms/
[DCDSP]
Description Set Profiles: A constraint language for Dublin Core Application Profiles. Nilsson, Mikael. 2008-03-31. DCMI Working Draft. URL: http://dublincore.org/documents/dc-dsp/
[OWL2-OVERVIEW]
OWL 2 Web Ontology Language Document Overview (Second Edition). W3C OWL Working Group. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-overview/
[PDF]
Document management -- Portable document format -- Part 1: PDF 1.7. 2008-07. ISO Standard. URL: https://www.iso.org/standard/51502.html
[SCHEMATRON]
ISO/IEC 19757-3:2016 Information technology -- Document Schema Definition Languages (DSDL) -- Part 3: Rule-based validation -- Schematron. 2016-01. ISO Standard. URL: https://www.iso.org/standard/55982.html
[SHEX]
Shape Expressions Language 2.next. 2018-09-06. W3C Community Group Draft Report. URL: https://shexspec.github.io/spec/
[SKOS-PRIMER]
SKOS Simple Knowledge Organization System Primer. Antoine Isaac; Ed Summers. W3C. 18 August 2009. W3C Note. URL: https://www.w3.org/TR/skos-primer/
[SKOS-REFERENCE]
SKOS Simple Knowledge Organization System Reference. Alistair Miles; Sean Bechhofer. W3C. 18 August 2009. W3C Recommendation. URL: https://www.w3.org/TR/skos-reference/
[StatDCAT-AP]
StatDCAT-AP – DCAT Application Profile for description of statistical datasets. Version 1.0.0. European Commission. 15 December 2016. URL: http://data.europa.eu/w21/26e43c99-4e0d-4448-808e-112b3057a38f
[VOCAB-DCAT-2-20180508]
Data Catalog Vocabulary (DCAT) - revised edition. Alejandra Gonzalez Beltran; David Browning; Simon Cox; Peter Winstanley. W3C. 8 May 2018. W3C Working Draft. URL: https://www.w3.org/TR/2018/WD-vocab-dcat-2-20180508/
[VOCAB-DCAT-20140116]
Data Catalog Vocabulary (DCAT). Fadi Maali; John Erickson. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/2014/REC-vocab-dcat-20140116/