The Profiles Vocabulary

W3C Working Draft

This version:
https://www.w3.org/TR/2019/WD-dx-prof-20190402/
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-implementations
Implementation report:
https://github.com/CSIRO-enviro-informatics/prof-implementations
Previous version:
https://www.w3.org/TR/2018/WD-dx-prof-20181218/
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 Vocabulary 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 Vocabulary 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 http://www.w3.org/ns/dx/prof/.
The PROF vocabulary, defined in OWL and encoded in RDF Turtle, is available at profilesont.ttl.

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 Second Public Working Draft addresses many, but not all, of the comments received on the First Public Working Draft of this vocabulary that was released in December, 2018. There are also some key issues still being discussed within the working group, such as what it means to be a profile of something, the relationships between profiles, and how and whether inheritance is included in the specification. See § 14. Changes for more change details and the GitHub issues below for further information on outstanding issues.

Issue 802: Does "profile of" require all or some elements? ON HOLD profile-descriptionON HOLD profile-guidancefeedback

From the Shex community: It is also unclear to us whether it is helpful to describe the relation of a profile to its underlying namespaces in terms of a relation of Profile to Standard. The standard-to-profile relation is characterized as one of general-to-specific, but when namespaces simply provide just a handful of their terms to a profile, it seems like a stretch to say that the profile is "profiling" each of the namespaces. https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Feb/0001.html

Issue 755: Definitions in Profiles Ontology ON HOLD profile-descriptionprof-2PWD

Definitions that need improving:

Issue 857: What is the level of the inheritance link? ON HOLD profile-descriptionON HOLD profile-guidance

This is a spin-off from #642. The example provided there uses the property prof:inheritedFrom between a Resource Descriptor and a Profile.

As @kcoyle noted, all of the requirements related to inheritance all speak of profile inheritance. From the draft profiles guidance document: "2..4 Profile inheritance [RPFINHER] Profiles may add to or specialise clauses from one or more base specifications. Such profiles inherit all the constraints from base specifications."

In addition we have this, which I think may also refer to resources rather than profiles:
"2.3 Profile of profiles [RPFPP] One can create a profile of profiles, with elements potentially inherited on several levels."

We've talked a lot about 'profile inheritance' and prof:isInheritedFrom may be about something slightly different (maybe a "consequence" of profile inheritance, but for the resources that embody these profiles).

NB: this issue is part of a wider discussion on profile inheritance (#748, #795 , #842, maybe #800, and 769), and we should try to avoid putting everything of that discussion into it!!!

Issue 507: What does prof:profileOf entail? ON HOLD profile-description

Copying discussion from #486: Karen, Rob, Karen, Nick, Karen. The basic question is: when one uses profileOf, as in "X prof:profileOf Y" what is entailed from Y when working with X?

From the ShEx community:

We were unsure what to make of "inheritance", as we are not aware of any generalized notion of inheritance that would make sense across implementation technologies. It would be helpful to motivate this with a testable use case, e.g., a server implementation which responds to Accept-Profile by calculating the "best" response for processing a Profile Ontology description. A test of inheritance would include the notion that inheriting imposes further constraints, and that the entity being inherited from may in turn inherit from something else. ShEx shape inheritance has this behavior.

https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Feb/0001.html

This document was published by the Dataset Exchange Working Group as a 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 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 March 2019 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 Vocabulary 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 Guidelines for Dublin Core Application Profiles [DCAP] and various profiles of OpenGeospatial Consortium specifications.

The Profiles Vocabulary 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 vocabulary 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 vocabulary provides a standardized, machine readable formalism for describing the context of profiles. The basis of this vocabulary 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 Role instances is provided in Section 8.

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/
rolehttp://www.w3.org/ns/dx/prof/role/
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]

4. Motivation

This section is non-normative.

Until this vocabulary's creation, 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:

4.1 Motivating Requirements

For the purposes of dataset exchange and with the lack of a formal W3C method for describing the objects related to profiles, the DXWG underwent a process of Use Case and Requirements gathering. They established the Dataset Exchange Use Case and Requirements document (the UCR document) [DCAT-UCR] which groups requirements for profiles into the following sections:

This Profiles Vocabulary document addresses many of those Requirements - those that can be addressed by describing profile components and relations - and the Requirements as described in the UCR document link back to the Use Cases that motivated them.

Additionally, the UCR document lists a further profiles Requirements section: 6.14 Profile and content negotiation however Requirements there are addressed by the related [PROF-CONNEG] document.

Issue 551: Harmonise Ont/Conneg references and content ON HOLD profile-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.

This section is non-normative.

Issue 400: Reference DC Singapore Framework ON HOLD profile-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 ModSpec ON HOLD profile-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

Vocabulary overview diagram
Figure 1 OWL [OWL2-OVERVIEW] overview diagram of this vocabulary

This vocabulary is for describing relationships between standards/specifications, profiles of them and supporting artifacts such as validating resources.

The model takes the dct:Standard Class as a starting point and defines a specialization, a Profile, which is a dct:Standard that profiles a dct:Standard or another Profile. Standardss or Profiles can have Resource Descriptors associated with them that define rules for implementation, provide guidance on how to implement, or play 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).

The remainder of this section is informative.

6.1 Initial Example

The example below illustrates the use of most parts of PROF and indicates how non-PROF profile metadata is stored alongside PROF metadata.

Figure 2 A full example profile described using common metadata and the Profiles Vocabulary
Example 1: A full example described using the Profiles Vocabulary in RDF (turtle)
@prefix dct: <http://purl.org/dc/terms/> .
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix role: <http://www.w3.org/ns/dx/prof/role/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<http://example.org/profile/x>  # a Profile; it's identifying URI
  a prof:Profile ;

  # common metadata for the Profile

  # the Profile's label
  rdfs:label "Profile X" ;

  # regular metadata, a basic description of the Profile
  rdfs:comment """This is a Profile of Dublin Core Terms used to describe items in
CSIRO's publications catalogue."""@en ;

  # regular metadata, URI of publisher
  dct:publisher <http://catalogue.linked.data.gov.au/org/O-000886> ;

  # PROF metadata

  # this is a profile of Dublin Core Terms, referenced by its namespace
  prof:isProfileOf <http://purl.org/dc/terms/> ;

  # this profile has a SHACL resource that constrains it's use of Dublin Core
  prof:hasResource [
    a prof:ResourceDescriptor ;

    # it's in Turtle format
    dct:format <https://w3id.org/mediatype/text/turtle> ;

    # it conforms to SHACL, here refered to by its namespace URI as a Profile
    dct:conformsTo <http://www.w3.org/ns/shacl#> ;

    # this resource plays the role of "Validation"
    # described in this ontology's accompanying Roles vocabulary
    prof:hasRole role:Validation ;

    # this resource's actual file
    prof:hasArtifact <http://example.org/profile/x/resource/validator.ttl>
  ] ;

  # other resources this profile contains
  prof:hasResource ... ;

  # a short code to refer to the Profile with when a URI can't be used
  prof:hasToken "profx"
.

6.2 Roles Vocabulary

A starting point vocabulary of Resource Role instances that is expected to be extended by implementers of PROF to suite specialised needs is provided within this vocabulary in Section 8.

7. Vocabulary Specification

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: Profile

OWL Classprof: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
Issue 521: Consider the addition of a conformanceTarget property ON HOLD profile-description

Following the OGC's Modular Specification [[modspec]], consider adding a property conformanceTarget (domain: prof:Profile, range: ?) that allows for the linking of Profiles to the sorts of thing or instances of the sorts of thing that are expected to conform to it.

What might the inverse property of this be?

7.3.1 Property: hasResource

RDF Property:prof:hasResource
OWL type:owl:ObjectProperty
Label:has resource
Definition:A resource which describes the nature of an artifact and the role it plays in relation to a profile
Range:prof:ResourceDescriptor

7.3.2 Property: isProfileOf

RDF Property:prof:isProfileOf
OWL type:owl:ObjectProperty
Label:is profile of
Definition:The subject of 'is profile of' defines constraints on the object which playes the role of a base specification
Domain:prof:Profile
Range:dct:Standard
Usage Note:A Profile may define constraints on the usage of one or more specifications. All constraints of these specifications are inherited, in the sense that an object conforming to a profile conforms to all the constraints specified the targets of prof:isProfileOf relations. This property is optional, allowing any specification to be declared at the root of a profile hierarchy using the Profile class

7.3.3 Property: isTransitiveProfileOf

RDF Property:prof:isTransitiveProfileOf
OWL type:owl:ObjectProperty
Label:is a transitive profile of
Definition:A specification for which this Profile defines constraints, possibly through a chain of isProfileOf relationships
Domain:prof:Profile
Range:dct:Standard
Usage note:This is a convenience predicate that may be used to declare all specifications (including profiles) that the subject profile requires an information resource to conform to. This avoids forcing clients to traverse a profile hierarchy to find all conformance implications and available resources. If present all such relationships should be present so a client can safely avoid hierarchy traversal
Issue 520: Illustrate transitivity with diagrams ON HOLD profile-descriptiondue for closing

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 3 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 vocabulary 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 vocabulary 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.

Figure 4 Property isTransitiveProfileOf in use. See the full explanation in the example text below.
Example 2: Property isInheritedFrom in use
# A profile that is within a hierarchy of profiles may wish to indicate it profiles
# things "further up the chain". To do this, prof:isTransitiveProfileOf can be used
# to indicate anything the profile is related to by a series of one or more
# prof:isProfileOf properties.

# Here the New Zealand profile of the ISO addressing standard is presented in a chain
# of profiles:

@prefix dct: <http://purl.org/dc/terms/> .
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix role: <http://www.w3.org/ns/dx/prof/role/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<http://linked.data.gov.au/def/iso19160-1-address-nz-profile>
  a prof:Profile ;
  rdfs:label "New Zealand Profile of ISO19160-1" ;
  rdfs:comment """This is a country-specific profile of the international
                  addressing standard, ISO19160-1:2015 (Address)""" ;
  prof:isProfileOf <http://linked.data.gov.au/def/iso19160-1-address> .

# The ISO thing that the NZ Profile profiles is actually a Web Ontology Language
# (OWL) version of the original ISO addressing standard
<http://linked.data.gov.au/def/iso19160-1-address>
  a prof:Profile ;
  rdfs:label "OWL Profile of ISO19160-1" ;
  rdfs:comment """This profile profiles both ISO19160-1 (Addressing) and also
                  the Web Ontology Language (OWL)""" ;
  prof:isProfileOf <https://www.iso.org/standard/61710.html> ,
                   <http://www.w3.org/2002/07/owl#> .

<https://www.iso.org/standard/61710.html>
  a dct:Standard ;
  rdfs:label "ISO 19160-1:2015 Addressing -- Part 1: Conceptual model" .

# Now, according to the semantics of prof:isTransitiveProfileOf, using the
# prof:isProfileOf statements above, one can infer the following additional
# statements:

<http://linked.data.gov.au/def/iso19160-1-address-nz-profile>
  prof:isTransitiveProfileOf <http://linked.data.gov.au/def/iso19160-1-address> ,
                             <https://www.iso.org/standard/61710.html> ,
                             <http://www.w3.org/2002/07/owl#> .

# These statements may help consumers understand which broad, well-known
# profiles data they have conforms to when they are presented only with its
# conformance to most specialised (lowest) profile in a hierarchy which they
# may not understand.

# In this example too, a user of the profile
# <http://linked.data.gov.au/def/iso19160-1-address-nz-profile> will also
# understand that data conforming to it is also conformant with OWL which is not
# in the direct hierarchy of addressing standards (iso19160-1-address-nz-profile >
# iso19160-1-address > ISO 19160-1:2015) but is critical to know about when using
# the specialised standard as it can indicate reasoning possibilities.

7.3.4 Property: hasToken

RDF Property:prof:hasToken
OWL type:owl:DatatypeProperty
Label:has token
Definition:A preferred alternative identifier for the Profile
Domain:prof:Profile
Range:xsd:token
Usage note:A simple lexical form of identifier that may be accepted in some circumstances, such as API arguments to reference this profile. This is a “preferred term”, since alternative identifiers may be declared and used by any implementation
Issue 453: Consider use of adms:identifier instead of prof:token ON HOLD profile-description

7.4 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 Classprof: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.4.1 Property: hasArtifact

RDF Property:prof:hasArtifact
Label:has artifact (resource)
Definition:The URL of a downloadable file with particulars such as its format and role indicated by a 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.4.2 Property: 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.4.3 Property: 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.4.4 Property: hasRole

RDF Property:prof:hasRole
Label:has role
Definition:The function of the described artifact in the expression of the Profile, such as a specification, guidance documentation, SHACL file etc.
Domain:prof:ResourceDescriptor
Range:skos:Concept
Usage note:A set of common roles are defined by the Profiles Vocabulary. These are not exhaustive or disjoint, and may be extended for situations where finer grained description of purpose is necessary. A resource may perform multiple roles

7.4.5 Property: isInheritedFrom

RDF Property:prof:isInheritedFrom
Label:is inherited from
Definition:This property indicates a Resource Descriptor described by this Profile’s base specification that is to be considered a Resource Descriptor for this Profile also
Domain:prof:ResourceDescriptor
Range:prof:Profile
Usage note:This property is created for the convenience of clients. When profile describers wish to allow clients to discover all resources relevant to a Profile without having to navigating an inheritance hierarchy of prof:profileOf relations, this predicate may be used to directly associate inherited Profile Descriptors with the Profile. If this property is present, it should be used consistently and all relevant resources a client may need to utilise the profile should be present and described using this predicate
Issue 840: Consider naming conventions for instances to make examples easier to read ON HOLD profile-description

#642 provides an example - a suggestion that naming conventions might make examples easier to follow was provided - this issue provides for the opportunity to get feedback on this particular issue.

Note - a PR needs to be prepared and accepted for the provided examples so that these can be reviewed in the light of this issue.

Issue 842: Replace isInheritedFrom with a subproperty of rdfs:isDefinedBy ON HOLD profile-descriptionprof-2PWD

Proposal: replace isInhertied from with a more general property that allows any ResourceDescriptor to directly indicate the profile that defines the role of this resource.

The rationale for a subproperty is that we can then add a property chain axiom to clarify the intent.

:specifiedBy rdf:type owl:ObjectProperty ;
rdfs:domain :ResourceDescriptor ;
rdfs:range dct:Standard ;
skos:definition "The base specification that defines the role of the related resource" ;
skos:usageNote "This property allows a client to determine which base specification declared the requirement or other role for this particular resource, allowing implementatios to flatten inheritance hierachies fo clietnts do not need to traverse a graph to locate all requirements. Implementations are responsible for determining if and how to use this property, and may choose some appropriate subset of resources. This property provides an optional inverse for the property hasResource"@en ;
owl:propertyChain ( :specifiedBy :hasResource ) ;
rdfs:label "specified by" .

To illustrate the use of prof:isInheritedFrom, the following example is given in both pictorial and code forms.

Figure 5 Property isInheritedFrom in use. Here the prof:ResourceDescriptor instance Profile Y, Resource Descriptor 2 refers to the same artifact (a constraints file) as Standard X, Resource Descriptor 1 and it is inherited by Profile Y from Standard X which Profile Y is a profile of.
Example 3: Property isInheritedFrom in use
# If Standard X, described using PROF, is given as having a Resource
# Descriptor, RD_1, with role "Full Constraints" as follows:

@prefix ex1: <http://example.org/profile1/> .
@prefix ex2: <http://example.org/profile2/> .
@prefix dct: <http://purl.org/dc/terms/> .Property isInheritedFrom in use.
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix role: <http://www.w3.org/ns/dx/prof/role/> .


ex1:Standard_X
    a dct:Standard ;
    dct:title "Standard X" ;
    prof:hasResource ex1:RD_1 .

ex1:RD_1
    a prof:ResourceDescriptor ;
    dct:conformsTo <http://www.w3.org/ns/shacl#> ;  # the SHACL standard
    dct:format <https://w3id.org/mediatype/text/turtle> ;  # the RDF Turtle format
    prof:hasRole role:fullConstraints ;      # this ResourceDescriptor is the total set of
                                             # constraints needed for validating data
                                             # against Standard X for conformance
    prof:hasArtifact ex1:constraints.ttl .

# then, a profile of Standard X, perhaps Profile Y, may use
# prof:isInheritedFrom to re-use that Resource Descriptor RD_1

ex2:Profile_Y
    a prof:Profile ;
    dct:title "Profile Y" ;
    prof:isProfileOf ex1:Standard_X ;  # this is a profile of Standard X
    prof:hasResource [
        a prof:ResourceDescriptor ;  # Resource Descriptor 2 in diagram
        prof:isInheritedFrom ex1:Standard_X ;  # this Resource Descriptor is inherited from
                                               # Standard X
        dct:conformsTo <http://www.w3.org/ns/shacl#> ;  # as above
        dct:format <https://w3id.org/mediatype/text/turtle> ;  # as above
        prof:hasRole role:partConstraints ;  # this ResourceDescriptor is now only Part Constraints
                                             # for Profile Y as it's implementing some of its own,
                                             # additional constraints (see next Resource Descriptor)
        prof:hasArtifact ex1:constraints.ttl  # direct URI reference to ex1:RD_1's artifact
    ] ,
    [
        a prof:ResourceDescriptor ;  # Resource Descriptor 2 in diagram. This is not inherited from anywhere
        dct:conformsTo <http://www.w3.org/ns/shacl#> ;
        dct:format <https://w3id.org/mediatype/text/turtle> ;
        # these constraints are Profile Y's on top of Standard X's
        prof:hasRole role:extensionConstraints ;  # Extension Constraints are those on top of
                                                  # another base specification's
        prof:hasArtifact ex2:extension_constraints.ttl  # a file within this Profile
    ] .

7.5 Class: ResourceRole

OWL Classprof: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. Such a vocabulary is provided in § 8. Resource Role Instances but other terms may also be used
Issue 452: Determine how to reference ResourceRole vocab ON HOLD profile-descriptiondue for closing

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. Resource Role Instances

Here are a small set of Resource Role Instances developed during the creation of this vocabulary. Application may choose to extend this list as required with new and specialised Resource Role instances for their purposes.

These instances are both owl:NamedIndividuals and skos:Concepts and have basic SKOS [SKOS-REFERENCE] properties.

8.1 Resource Role: Constraints

SKOS Concept role:constraints
Pref Label:Constraints
Definition:Descriptions of obligations, limitations or extensions that the profile defines
Usage Note:Use this Role when you want to indicate the constraints that the associated Profile imposes on to of base specifications

8.2 Resource Role: Example

SKOS Concept role:example
Pref Label:Example
Definition:Sample instance data conforming to the profile
Usage Note:Use this Role when you want to provide instances of data conforming to the profile to inform users

8.3 Resource Role: Guidance

SKOS Concept role:guidance
Pref Label:Guidance
Definition:Documents, in human-readable form, how to use the profile
Usage Note:Many existing profiles treat their human-readable forms (PDF documents etc.) as authoritative. This role is suggestive of non-authoritativeness. For a role for a human-readable resource that is authoritative, see Specification.

8.4 Resource Role: Mapping

SKOS Concept role:mapping
Pref Label:Mapping
Definition:Describes conversions between two specifications
Note
This Role may necessitate the introduction to PROF of mappingFrom and mappingTo properties.
Issue 810: Introduce mappingFrom and mappingTo properties ON HOLD profile-description

The Resource Role Mapping, if found to be necessary or useful, might need mappingFrom and mappingTo properties defined to indicate what is mapped to what.

8.5 Resource Role: Schema

SKOS Concept role:schema
Pref Label:Schema
Alternate Label:Shape, Structure
Definition:Machine-readable structural descriptions of data defined by the profile

8.6 Resource Role: Specification

SKOS Concept role:specification
Pref Label:Specification
Definition:Defining the profile in human-readable form
Usage Note:This role indicates authoritativeness. For a role for a human-readable resource that is not authoritative, see Guidance

8.7 Resource Role: Validation

SKOS Concept role:validation
Pref Label:Validation
Definition:Supplies instructions about how to verify conformance of data to the profile
Usage Note:This role implies inclusion or import of inherited constraints

8.8 Resource Role: Vocabulary

SKOS Concept role:vocabulary
Pref Label:Vocabulary
Definition:Defines terms used in the profile specification

9. Examples

This section is non-normative.

This section contains a few examples of PROF in use to demonstrate aspects of this vocabulary. 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 vocabulary's use.

9.1 DCAT-AP

This example showcases this vocabulary's description of parts of an existing, well-known, profile.

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

The figure uses elements from this vocabulary to describe part of the DCAT-AP Profile graphically - PDF & RDF resources only - to simplify the example.

Figure 6 Part of the DCAT-AP Profile described using this ontology. Here two two Resource Descriptors are shown relating to the Profile indicating resources with "Guidance" and "Constraints" roles.

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

In RDF (turtle format), DCAT-AP is described using the Profiles Vocabulary, with many properties not listed in the summary figure and description above as:

Example 4: DCAT-AP described using Profile Ontology in RDF (turtle)
@prefix dc:    <http://purl.org/dc/elements/1.1/> .
@prefix prof:  <http://www.w3.org/ns/dx/prof/> .
@prefix role:  <http://www.w3.org/ns/dx/prof/role/> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .

<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> ;

  # 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> ;
.

# The DCAT-AP profile itself has profiles: here GeoDCAT-AP v1.0 is given
<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/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 role: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 role: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 role: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 role:FullConstraints ;
.

9.2 DCAT-AP hierarchy

This example showcases this vocabulary being used to indicated profiles within a complex 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-AP, GeoDCAT-AP_IT.

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

DCAT-AP and related profiles in a hierarchy
Figure 7 DCAT-AP and related profiles in a hierarchy. The Profile labelled '?' shows a potential future profile instance that profiles both DCAT-BE & StatDCAT-AP.
Example 5: The GeoDCAT-AP profile hierarchy described using Profile Ontology in RDF (turtle)
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<http://www.w3.org/ns/dcat>
  a dct:Standard ;

<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> ;

# an example as per the Figure above, not an existing profile
<http://example.org/profile/questionmark>
  a prof:Profile ;
  rdfs:label "?" ;
  prof:isProfileOf
      <https://joinup.ec.europa.eu/solution/statdcat-application-profile-data-portals-europ> ,
      <http://dcat.be> .

Since there are no cardinality restrictions on either the property prof:isProfileOf or other restrictions on 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.3 CSIRO Dummy Dublin Core AP

This example uses a dummy profile created for this document to show how PROF describes profiles created according to the Guidelines for Dublin Core Application Profiles [DCAP].

The DCAP Guidelines document "explains the key components of a Dublin Core Application Profile and walks through the process of developing a profile". It "does not address the creation of machine-readable implementations of an application profile" which is what PROF does.

In this example, a dummy profile of Dublin Core TERMS [DCTERMS] is created to characterise documents in a hypothetical "ePublish" platform. The dummy profile contains many parts:

CSIRO Dummy DCAP Profile
Figure 8 CSIRO Dummy DCAP Profile characterised using PROF. Only two of the four Resource Descriptors in the RDF below are shown.
Example 6: The GeoDCAT-AP profile hierarchy described using Profile Ontology in RDF (turtle)
#
#   This document is a description, according to the Profiles Vocabulary (see https://www.w3.org/TR/dx-prof/)
#   of a dummy "CSIRO ePublish Repository" profile of the Dubline Core standard. This profile is known as a DCAP -
#   Dublin Core Application Profile
#
#   See http://dublincore.org/documents/profile-guidelines/ for more information about Dublin Core Application Profiles
#
@prefix dct: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix role: <http://www.w3.org/ns/dx/prof/role/> .


# Base Specification being profiled
<http://dublincore.org/documents/2012/06/14/dcmi-terms/> a dct:Standard ;
    rdfs:label "DCMI Metadata Terms" .

# dummy CSIRO profile of DC for ePublish repository
# URIs not dereferencable
<http://test.linked.data.gov.au/test/def/CSIRO-ePub-DCAP>
    a                 prof:Profile ;
    rdfs:label        "CSIRO's profile of DC for ePublish" ;
    prof:isProfileOf    <http://dublincore.org/documents/2012/06/14/dcmi-terms/> ;
    prof:token        "ePubDC"^^xsd:Token ;
    prof:hasResource  _:1 , _:2 , _:3 , _:4 .

# example's code repository home
_:1
    a                 prof:ResourceDescriptor ;
    rdfs:label        "Profile Specifcation" ;
    dct:format        <https://w3id.org/mediatype/text/html> ;
    # the official written text specifying the Profile
    prof:hasRole      role:Specification ;
    prof:hasArtifact  <http://linked.data.gov.au/def/CSIRO-ePub-DCAP/> .

# this is an RDF (turtle) version of the DSP constraints for this profile
_:2
    a                 prof:ResourceDescriptor ;
    rdfs:label        "Full constraints in RDF" ;
    dct:conformsTo    <http://dublincore.org/documents/2008/03/31/dc-dsp/> ; # the constraints conform to the DSP spec
    dct:format        <https://w3id.org/mediatype/text/turtle> ; # it's in Turtle format
    # this is full constraints: if your instance passes these, you're compliant with the profile
    prof:hasRole      role:Constraints ;
    prof:hasArtifact  <http://test.linked.data.gov.au/test/def/CSIRO-ePub-DCAP/constraints.ttl> .

_:3
    a                 prof:ResourceDescriptor ;
    rdfs:label        "Full constraints in DSP constraint language" ;
    dct:conformsTo    <http://dublincore.org/documents/2008/03/31/dc-dsp/> ; # the constraints conform to the DSP spec
    dct:format        <https://w3id.org/mediatype/text/plain> ; # it's in plain text format
    # this is full constraints: if your instance passes these, you're compliant with the profile
    prof:hasRole      role:Constraints ;
    prof:hasArtifact  <http://test.linked.data.gov.au/test/def/CSIRO-ePub-DCAP/constraints-dcap-syntax.txt> .

# this resource is a PDF file in the def about how to use the CSIRO-ePub-DCAP
_:4
    a                 prof:ResourceDescriptor ;
    rdfs:label        "Guidance document" ;
    dct:format        <https://w3id.org/mediatype/application/pdf> ;
    # general guidance info on how to use/implement this Profile
    prof:hasRole      role:Guidance ;
    prof:hasArtifact <http://test.linked.data.gov.au/test/def/CSIRO-ePub-DCAP/HowTo.pdf> .

This DCAP example shows, among other things, that a Profile may contain multiple Resource Descriptor individuals that perform the same Resource Role (here Constraints) that are differentiated on other bases, here on format: plain text & RDF (turtle).

9.4 Geoscience Australia's Profile of ISO19115-1:2014

This example shows a non-RDF profile of a non-RDF standard: ISO19115-1:2014 (Geographic information) [ISO-19115-1-2014].

Communities commonly make profiles of the International Organization for Standardization's standard ISO19115-1:2014 Geographic information -- Metadata -- Part 1: Fundamentals used for cataloguing spatial datasets. Geoscience Australia, Australia's national geological survey agency, has created a profile that constrains ISO19115-1:2014 in ways such as making optional properties in the standard mandatory for profile conformance.

The GA Profile of ISO19115 is published online as a collection of resources with an index document with the persistent URI http://pid.geoscience.gov.au/def/schema/ga/ISO19115-1-2014.

Although not initially formulated with PROF in mind, nevertheless the various parts of the GA Profile of ISO19115 can be characterised using PROF as per Figure 9 and the example RDF below. Note that the persistent URIs assigned to the profile by Geoscience Australia are used within the PROF description.

GA Profile of ISO19115 in PROF
Figure 9 The GA Profile of ISO19115 characterised using PROF.
Example 7: GA Profile of ISO19115 according to PROF in RDF (turtle)
@prefix : <http://www.w3.org/ns/dx/prof/examples/ga.ttl#> .
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix roles: <http://www.w3.org/ns/dx/prof/roles/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

:ISO19115-1-2014
    a dct:Standard ;
    rdfs:label "ISO ISO19115-1:2014" ;
    rdfs:comment "The international standard ISO19115-1:2014 Geographic information - Metadata" ;
    dc:publisher "International Organization for Standardization" ;
    dct:source <https://www.iso.org/standard/53798.html>
.

<http://pid.geoscience.gov.au/def/schema/ga/ISO19115-1-2014>
    a prof:Profile ;
    prof:token "iso19115-ga" ;
    rdfs:label "ISO19115-1:2014 GA Profile";
    rdfs:comment """Provides a means to declare, and discover implementation resources to check, implementations of geographic metadata schema conforming to GA's profile."""@en;
    dct:publisher <http://pid.geoscience.gov.au/org/ga/geoscienceaustralia> ;
    prof:profileOf :ISO19115-1-2014 ;
    prof:hasResource :web , :spec , :schema , :constraints ;
.

:web
    a prof:ResourceDescriptor ;
    rdfs:label "GA Profile guidance document online" ;
    prof:hasRole roles:guidance ;
    dct:conformsTo :WebPage ;
    dct:format <https://w3id.org/mediatypes/text/html> ;
    prof:hasArtifact <http://pid.geoscience.gov.au/def/schema/ga/ISO19115-1-2014> ;
.

:spec
    a prof:ResourceDescriptor ;
    rdfs:label "GA Profile specification document";
    prof:hasRole roles:specification ;
    dct:format <https://w3id.org/mediatypes/application/pdf> ;
    prof:hasArtifact <http://pid.geoscience.gov.au/dataset/ga/122551> ;
.

:schema
    a prof:ResourceDescriptor ;
    rdfs:label "GA Profile XML Schema";
    prof:hasRole roles:specification ;
    dct:conformsTo :XSDSchema ;
    dct:format <https://w3id.org/mediatypes/text/xml> ;
    prof:hasArtifact <http://pid.geoscience.gov.au/def/schema/ga/ISO19115-3-2016/gapm.xsd> ;
.

:constraints
    a prof:ResourceDescriptor ;
    rdfs:label "GA Profile Schematron" ;
    prof:hasRole roles:fullConstraints ;
    dct:conformsTo :Schematron ;
    dct:format <https://w3id.org/mediatypes/text/xml> ;
    prof:hasArtifact <http://pid.geoscience.gov.au/def/schema/ga/schematron-rules-ga.sch> ;
.

:WebPage a dct:MediaTypeOrExtent ;
    rdfs:label "Web Page" ;
    rdfs:comment "A document written in HyperText Markup Language designed for human reading via a web browser." ;
    dct:source <https://www.w3.org/html/> ;
.

:Schematron a dct:MediaTypeOrExtent ;
    rdfs:label "Schematron" ;
    rdfs:comment "A language for making assertions about the presence or absence of patterns in XML documents." ;
    dct:source <http://schematron.com> ;
.

9.5 Asset Description Metadata Schema

This example shows a Profile, some of whose Resource Descriptors conform to standards.

The Asset Description Metadata Schema (ADMS) [VOCAB-ADMS] is a profile of DCAT, used to describe semantic assets. Both ADMS the Profile and two of its Resource Descriptors are published according to W3C specifications for Recommendations and Working Group Notes.

ADMS profile of DCAT
Figure 10 The ADMS profile of DCAT.
Example 8: ADMS profile of DCAT according to PROF in RDF (turtle)
@prefix : <http://www.w3.org/ns/dx/prof/examples/adms.ttl#> .
@prefix prof: <http://www.w3.org/ns/dx/prof/> .
@prefix roles: <http://www.w3.org/ns/dx/prof/roles/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .


#
#   A series of standards defined in this examples document
#
:W3Cnote
  rdf:type dct:Standard ;
  rdfs:label "W3C Working Group Note Document" ;
.

:W3Crec
  rdf:type dct:Standard ;
  rdfs:label "W3C Recommendation Document" ;
.


#
#   ADMS, described as a profile of DCAT (original)
#
:ADMS
    a prof:Profile ;
    rdfs:label "ADMS" ;
    # this URI is for DCAT (original) as defined in the DCAT examples
    prof:profileOf <http://www.w3.org/ns/dx/prof/examples/dcat.ttl#dcat2014> ;
    prof:hasResource :ADMS-note ,
                     :ADMS-rdf ,
.

:ADMS-note
    a prof:ResourceDescriptor ;
    rdfs:label "ADMS specification document" ;
    prof:hasRole roles:specification ;
    dct:conformsTo prof:W3Cnote ;
    dct:format <https://w3id.org/mediatypes/text/html> ;
    prof:hasArtifact <https://www.w3.org/TR/vocab-adms/> ;
.

:ADMS-rdf
    a prof:ResourceDescriptor ;
    rdfs:label "ADMS RDF vocabulary" ;
    prof:hasRole roles:vocabulary ;
    dct:conformsTo <https://www.w3.org/TR/owl2-rdf-based-semantics/> ,
                   <https://www.w3.org/TR/rdf-schema/> ;
    dct:format <https://w3id.org/mediatypes/text/turtle> ;
    prof:hasArtifact <https://www.w3.org/ns/adms> ;
.

# additional information about DCAT (original) not present in the DCAT example
<http://www.w3.org/ns/dx/prof/examples/dcat.ttl#dcat-orig>
    dct:conformsTo :W3Crec .

10. Test Suite

A software suite is made available to test implementations of this vocabulary 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 tools ON HOLD profile-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. Implementations

This section is non-normative.

Implementation conformance reports for this vocabulary are given in:

Issue 467: Model implementation reporting as done in SHACL ON HOLD profile-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 implementation ON HOLD profile-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. Alignments

This section is non-normative.

This section lists alignments between PROF and other, related, ontologies.

12.1 Dataset Catalogue Vocabulary

Note: Status of PROF/DCAT alignment
PROF/DCAT relations are being addressed as a major part of PROF's Third Public Working Draft

PROF is considered a specialisation of the revised version of the Dataset Catalogue Vocabulary [VOCAB-DCAT-2] for the purpose of cataloguing profiles. With this in mind, the main PROF classes - Profile and Resource Descriptor - specialise (are sub classes of) DCAT's Resource and Distributions respectively. This alignment is not normative, but is provided as a recommended way to consider general metadata needs when describing profiles.

These specialisations are indicated in Figure 11 below as well as the data element mapping table that follows it.

Alignment of PROF with DCAT
Figure 11 Alignment of PROF with DCAT [VOCAB-DCAT-2].

The following table relates PROF and DCAT elements.

PROF elementMapping propertyDCAT elementNotes
prof:Profilerdfs:subClassOfdcat:Resourceprof:Profile is not a sub class of dcat:Dataset
prof:ResourceDescriptorrdfs:subClassOfdcat:Distribution

While DCAT is referenced in the main PROF RDF file, the following separate RDF file contains just the mappings included in the table above too:

12.2 Asset Description Metadata Schema

Issue 240: PROF - ADMS alignment ON HOLD profile-description

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

The Asset Description Metadata Schema (ADMS) [VOCAB-ADMS] is a profile of DCAT, used to describe semantic assets. PROF is aligned with ADMS as per Figure 12 and table below.

Due to PROF being aligned with the revised version of DCAT and ADMS also being aligned with DCAT, classes and properties of the two vocabularies may be sensibly used beyond the mappings presented here. In particular the fact that both prof:Profile and adms:Asset are non-disjoint sub classes of dcat:Resource, albeit that the latter is such via being a sub class of dcat:Dataset which subclasses dcat:Resource, means that resources could easily be dually typed as being of both prof:Profile and adms:Asset.

Alignment of PROF with ADMS
Figure 12 Alignment of PROF with DCAT [VOCAB-ADMS].

The following table relates PROF and ADMS elements.

PROF elementMapping propertyADMS element
prof:ResourceDescriptorrdfs:subClassOfadms:AssetDistribution

The following RDF file contains just the mappings included in the table above:

12.3 Dublin Core Terms

PROF makes use of Dublin Core Terms [DCTERMS] directly with the PROF class prof:Profile being a sub class of dct:Standard and two Dublin Core Terms properties, dct:format & dct:conformsTo being recommended within PROF for use in describing instances of the prof:ResourceDescriptor class.

PROF is aligned with Dublin Core Terms as per Figure 13 and table below.

Alignment of PROF with Dublin Core Terms
Figure 13 Alignment of PROF with Dublin Core Terms [DCTERMS].

The following table relates PROF and Dublin Core Terms elements.

PROF elementMapping propertyDCT element
prof:Profilerdfs:subClassOfdct:Standard

While Dublin Core Terms is referenced in the main PROF RDF file, the following RDF file contains just the mappings included in the table above:

12.4 The Provenance Ontology

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 797: PROF relationship to other vocabularies ON HOLD profile-descriptionfeedback

From Leslie Sikos

Relationship with standard and de facto standard vocabularies and ontologies, such as Dublin Core, PROV-O, and SKOS, should be defined (more) clearly in the specification and formally in the ontology file itself. For example, the range of :isTransitiveProfileOf is defined to be dct:Standard—much more similar definitions would be needed.

https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Jan/0020.html

The Provenance Ontology [PROV-O] is used to represent and interchange provenance information.

Note: Status of PROV-O alignment
Alignment of PROF with PROV-O will be addressed in PROF's Third Public Working Draft.

12.5 Web Ontology Language

PROF is a vocabulary formulated using the Web Ontology Language (OWL) [OWL2-OVERVIEW]. In addition to the basic modelling mechanics of PROF that use OWL, for example PROF classes being defined as owl:Class objects and PROF properties being OWL owl:ObjectProperty or other OWL property types, some of the core PROF modelling concepts relate to OWL ontology concepts.

PROF is aligned with OWL at a conceptual modelling level as per Figure 14 and table below.

Alignment of PROF with OWL
Figure 14 Alignment of PROF with OWL [OWL2-OVERVIEW].
PROF elementMapping propertyOWL element
prof:isProfileOf?owl:imports

The following RDF file contains just the mappings included in the table above:

Issue 696: Alignment / differentiation with OWL ON HOLD profile-descriptionfeedback

Raised by Reviewer 1 of the Profiles Ontology ESWC paper and elsewhere: PROF must differentiate itself from OWL, specifically prof:isProfileOf v. owl:imports.

12.6 Vocabulary of a Friend

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

Vocabulary of a Friend (VOAF) is a vocabulary specification providing elements allowing the description of vocabularies (RDFS vocabularies or OWL ontologies) [VOAF]. Due to VOAF being defined for use with RDF resources only, PROF as an alignment with VOAF which is instance-specific: resources described by PROF's prof:ResourceDescriptor class with the property prof:resourceRole linking to the Resource Role role:Vocabulary or a specialized version of it may be a voaf:Vocabulary.

Alignment of PROF with VOAF
Figure 15 Alignment of PROF with VOAF [VOAF].
PROF elementMapping propertyVOAF element
instance of rdf:Resource related to an instance of a prof:ResourceDescriptor via prof:hasArtifact that also relates to the Role role:Vocabulary or specialisation thereof instance of voaf:Vocabulary

The following RDF file contains just the mappings included in the table above:

12.7 OGC/ISO Modular Specification

Issue 403: Reference OGC ModSpec ON HOLD profile-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.

Issue 737: Refer to Open Geospatial Consortium Profiling ON HOLD profile-guidanceeditorial

OGC profiling was in the Profile Guidance document in the related work and needs to be properly mentioned again, somewhere

Issue 791: PROF Voc & OGC Testbed 14: Characterization of RDF Application Profiles ON HOLD profile-description

12.8 Simple Knowledge Organization System

The Simple Knowledge Organization System (SKOS) [SKOS-REFERENCE] is a data model knowledge organization systems, such as thesauri, taxonomies, classification schemes and subject heading systems. PROF declares its instances of Resource Role to be instances of the skos:Concept class to indicate that they should be considered a hierarchy of concepts within a skos:ConceptScheme. Since they are SKOS hierarchy and it is recommended that implementers of PROF extend the hierarchy for their own needs, implementers should consider creating new Resource Role (also skos:Concept) and relating them to the existing instances with SKOS properties, particularly skos:narrower/skos:broader.

Alignment of PROF with SKOS
Figure 16 Alignment of PROF with SKOS [SKOS-REFERENCE].
PROF elementMapping propertySKOS element
prof:ResourceRolerdfs:subClassOfskos:Concept

While SKOS is referenced in the main PROF RDF file, the following RDF file contains just the mappings included in the table above:

Issue 405: Complete PROF/x alignments ON HOLD profile-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.

13. Security and Privacy

This section is non-normative.

Issue 479: Profiles Ont doc Security and Privacy ON HOLD profile-description

14. Changes

This section is non-normative.

Changes since the First Public Working Draft are:

A comments disposition document is in preparation and will be available from the Data Exchange Working Group home page.

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

Issue 204: Clarify any relationship between profiles and validation languages (6.1) ON HOLD profile-guidancef2f3requirement

#75

RESPONSE FOR 204

Issue 205: Profiles have URI identifiers that resolve to more detailed descriptions (6.1) ON HOLD profile-guidancedue for closingf2f3requirement

#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 vocabulary 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) ON HOLD profile-guidancef2f3requirement

#75

RESPONSE FOR 207

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

Issue 208: Application profiles need a rich expression for the validation of metadata (6.1) ON HOLD profile-guidancef2f3requirement

#75

RESPONSE FOR 208

This is addressed by Profiles using Resource Descriptors from this vocabulary 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) ON HOLD profile-guidancef2f3requirement

#75

RESPONSE FOR 209

Issue 210: Profiles must support declaration of vocabulary constraints (6.1) ON HOLD profile-guidancef2f3requirement

#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) ON HOLD profile-guidancef2f3requirement

#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) ON HOLD profile-guidancef2f3requirement

#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) ON HOLD profile-guidancef2f3requirement

#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) ON HOLD profile-guidancef2f3requirement

#75

RESPONSE FOR 214

Issue 215: Profiles describe conformance to metadata standards (6.1) ON HOLD profile-guidancef2f3requirement

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 vocabulary may indicate that they are a profileOf another Profile.

Issue 216: Profiles extend or refine (UC 5.37) ON HOLD profile-guidancef2f3requirement

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) ON HOLD profile-guidancef2f3profile-negotiationrequirement

RESPONSE FOR 217

Issue 222: Profiles must support discoverability via search engines [ID40] (UC 5.40) ON HOLD profile-guidancef2f3requirementrequires 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) ON HOLD profile-guidanceplenary-approvedrequirement

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://isbnsearch.org/isbn/9780838913468

RESPONSE FOR 255

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) ON HOLD profile-guidanceplenary-approvedrequirementrequires 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) ON HOLD profile-descriptionplenary-approvedrequirement

Entered from Google Doc

RESPONSE FOR 279

Using this vocabulary, 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) ON HOLD profile-descriptionON HOLD profile-guidanceplenary-approvedrequirement

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) ON HOLD profile-guidanceplenary-approvedprofile-negotiationrequirementrequires discussion

Entered from Google Doc

Suggested re-wording: a profile must have an identifier

RESPONSE FOR 284

Using this vocabulary, 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) ON HOLD profile-guidanceplenary-approvedprofile-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 vocabulary, a person or machine may discover either Resource Descriptor resources describing any sort of document relevant to the profile or other Profiles.

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) ON HOLD profile-guidanceplenary-approvedrequirementrequires discussion

Entered from Google Doc

RESPONSE FOR 288

Graph navigation of profiles' information described using this vocabulary 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 it ON HOLD profile-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. DCMI Usage Board. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dcmi-terms/
[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/
[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/
[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/

B.2 Informative references

[DCAP]
Guidelines for Dublin Core Application Profiles. Karen Coyle; Thomas Baker. DCMI. 18 May 2009. DCMI Recommended Resource. URL: http://dublincore.org/documents/profile-guidelines/
[DCAT-UCR]
Dataset Exchange Use Cases and Requirements. Jaroslav Pullmann; Rob Atkinson; Antoine Isaac; Ixchel Faniel. W3C. 17 January 2019. W3C Note. URL: https://www.w3.org/TR/dcat-ucr/
[DCDSP]
Description Set Profiles: A constraint language for Dublin Core Application Profiles. Mikael Nilsson. DCMI. 31 March 2008. DCMI Working Draft. URL: http://dublincore.org/documents/dc-dsp/
[GeoDCAT-AP]
GeoDCAT-AP: A geospatial extension for the DCAT application profile for data portals in Europe. Version 1.0.1. European Commission. 2 August 2016. URL: http://data.europa.eu/w21/81fd7288-6929-4b42-8707-2da604490d30
[ISO-19115-1-2014]
Geographic information -- Metadata -- Part 1: Fundamentals. ISO/TC 211. ISO. 2014. International Standard. URL: https://www.iso.org/standard/53798.html
[PDF]
Document management -- Portable document format -- Part 1: PDF 1.7. 2008-07. ISO Standard. URL: https://www.iso.org/standard/51502.html
[PROF-CONNEG]
Content Negotiation by Profile. 2018-12-18. W3C First Public Working Draft. URL: https://www.w3.org/TR/2018/WD-dx-prof-conneg-20181218/
[PROF-GUIDANCE]
Profile Guidance. 2018-12-31. W3C Editor's Draft. URL: https://www.w3.org/TR/profile-guidance/
[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
[PROV-O]
PROV-O: The PROV Ontology. Timothy Lebo; Satya Sahoo; Deborah McGuinness. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-o/
[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/
[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
[VOAF]
Vocabulary of a Friend (VOAF). Bernard Vatant. OKFN. 24 May 2013. URL: http://purl.org/vocommons/voaf
[VOCAB-ADMS]
Asset Description Metadata Schema (ADMS). Phil Archer; Gofran Shukair. W3C. 1 August 2013. W3C Note. URL: https://www.w3.org/TR/vocab-adms/
[VOCAB-DCAT-2]
Data Catalog Vocabulary (DCAT) - revised edition. Alejandra Gonzalez Beltran; David Browning; Simon Cox; Peter Winstanley. W3C. 16 October 2018. W3C Working Draft. URL: https://www.w3.org/TR/vocab-dcat-2/
[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/