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.
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
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!!!
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?
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.
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 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:
[PROF-GUIDANCE] the top-level general recommendations and guidance on profiling.
It gives an overview of all DXWG documents on profiles and is the recommended starting point
[PROF] this document, an RDF vocabulary that describes profiles and related resources
[PROF-CONNEG] the specific guidance on how to negotiate for Internet resource content using profiles
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 6Conceptual Model,
Section 7Vocabulary Specification &
Section 9Test 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.
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:
machine readable constraint languages
(e.g. the abstract (Dublin Core's Description Set Profiles [DCDSP]) ot the more concrete (SHACL [SHACL] & ShEx
[SHEX]).
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:
its dependence on standards or other profiles
inheritance of profile information from the things being profiled, or
related profile resources
guidance documents in addition to formal constraints
equivalent constraints written in different constraint languages for different forms of resource, e.g.
SHACL for RDF and Schematron [SCHEMATRON] for XML.
With a mechanism to relate profiles to standards and other profiles, profile hierarchies can be established which
will:
assist with the reuse of existing profiles
one can profile another profile, adding a small set of additional constraints and declaring compatibility with all profiled standards.
reducing the total effort and information necessary to specify a profile
allow for machine interpretation of profiles and automated profile negotiation with fallback options
if a client requests a profile which a server cannot deliver, a server may be able to instead deliver a
more generic version of the requested resource, using a profile link to the thing it profiles
a client may be able to generate a request that already indicates acceptable fallback options for resources
when the primary requested profile is unavailable
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.
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 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
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
Figure 1OWL [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:
alignments to other vocabularies, some of which are normative, and others which are for guidance only
additional axioms, which can be useful in some contexts
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".
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.
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
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
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 4Property isTransitiveProfileOf in use. See the full explanation in the example text below.
# 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.
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
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)
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
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
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
#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.
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.
# 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
] .
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.
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.
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.
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.
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:
a profile overview document
a How To document offering guidance on how to use the profile
two constraint language files - both conforming to DCAP's constraint syntax in plain text and RDF (turtle) formats
two profile description files - one an image (the Figure 8 below) and the other an RDF file (the example RDF below)
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.
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.
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.
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.
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:
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.
Figure 11Alignment of PROF with DCAT [VOCAB-DCAT-2].
The following table relates PROF and DCAT elements.
PROF element
Mapping property
DCAT element
Notes
prof:Profile
rdfs:subClassOf
dcat:Resource
prof:Profile is not a sub class of dcat:Dataset
prof:ResourceDescriptor
rdfs:subClassOf
dcat: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:
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.
Figure 12Alignment of PROF with DCAT [VOCAB-ADMS].
The following table relates PROF and ADMS elements.
PROF element
Mapping property
ADMS element
prof:ResourceDescriptor
rdfs:subClassOf
adms:AssetDistribution
The following RDF file contains just the mappings included in the table above:
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.
Figure 13Alignment of PROF with Dublin Core Terms [DCTERMS].
The following table relates PROF and Dublin Core Terms elements.
PROF element
Mapping property
DCT element
prof:Profile
rdfs:subClassOf
dct: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:
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
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.
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.
Figure 14Alignment of PROF with OWL [OWL2-OVERVIEW].
PROF element
Mapping property
OWL element
prof:isProfileOf
?
owl:imports
The following RDF file contains just the mappings included in the table above:
Raised by Reviewer 1 of the Profiles Ontology ESWC paper and elsewhere: PROF must differentiate itself from OWL, specifically prof:isProfileOf v. owl:imports.
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.
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.
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.
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.
Issue 204: Clarify any relationship between profiles and validation languages (6.1)
Issue 205: Profiles have URI identifiers that resolve to more detailed descriptions (6.1)
Issue 207: Each application profile needs to be documented, preferably by showing/reusing what is common across profiles (6.8.1)
Issue 208: Application profiles need a rich expression for the validation of metadata (6.1)
Issue 209: Profiles SHOULD have both both machine and human-readable views. (6.1)
Issue 210: Profiles must support declaration of vocabulary constraints (6.1)
Issue 211: Profiles should provide both machine and human readable views (6.1)
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)
Issue 213: Profiles must support a view that includes all inherited constraints clearly identifying the parent profile the constraint is defined in (6.1)
Issue 214: A mechanism must be available to identify conformance to each inherited profile given conformance to a profile that specialises it (6.1)
Issue 215: Profiles describe conformance to metadata standards (6.1)
Issue 217: Responses can conform to multiple, modular profiles (UC 5.3)
Issue 222: Profiles must support discoverability via search engines [ID40] (UC 5.40)
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)
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)
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)
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)
Issue 284: A profile must have an identifier that can be served with a response to an API or http request. [ID2] (5.2)
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)
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)
Issue 455: Provide an example of both a profile and a resource adhereing to it
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.
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.
This is addressed by Profiles using Resource Descriptors from this vocabulary which then implement constraint
languages with various Roles such as "Full Constraints".
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
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
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)
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.
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.
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.
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.
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.
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:
